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IL. INTRODUCTION 


A. BACKGROUND 

Silas B. Hays Army Community Hospital (SBHACH) is a large, full service 
medical department activity (MEDDAC) providing health care to active duty, retired, 
and dependent personnel living in and around Fort Ord. The MEDDAC also provides 
regional medical services to personnel from Hunter Liggett Military Reservation, 
Presidio of Monterey, Sacramento Army Depot, United States Naval Postgraduate 
School, and the Sharpe Army Depot. SBHACH's annual operating budget is over seven 
million dollars and in fiscal year 1988, over 460,000 patients were treated. The 
hospital consists of 13 major medical departments which provide inpatient and 
outpatient service, major surgical services, military medical support, and veterinary 
service. In addition, SBHACH is a teaching hospital for Army doctors and provides 
occupational health to civilian employees. The goal of SBHACH is to provide its 
patients with the best medical care possible. 

The quality of the medical care provided depends on factors such as the quality 
of the hospital personnel and the effective use of available resources, e.g. personnel, 
money, time, and medical supplies. Another factor, the efficient use of resources, 
indirectly affects the quality of care provided because this factor will determine the 
continued availability of the resources. One of the biggest obstacles SBHACH faces 


in trying to reach its goal is the limited resources with which it must operate. 


SBHACH doctors and administrators must constantly deal with resource 
constraints. They are continually searching for more efficient and effective resource 
management to deal with these constraints while, at the same time, improving the 
quality of care provided to the patients. In searching for the balance between cost 
efficiency and quality of care, hospital administrators are turning to information 
systems, both automated and manual, in the belief that better information will help 


them operate more cost effectively. 


B. PURPOSE 

The purpose of this thesis is to study the current management information systems 
in place at Silas B. Hays Army Community Hospital and determine if these systems 
are meeting the needs of department managers within the hospital. In identifying the 
requirements of key department decision makers, we will propose improvements to the 
information system where the current system fails to meet the department manager’s 
needs. Ultimately, the thesis will provide a design for an information system which will 
meet the needs of department decision makers more effectively and efficiently than 


current systems. 


C. SCOPE 

Due to time limitations, the research did not encompass the entire hospital 
operation. Therefore, after initial interviews and some detailed study, one department 
was selected based on its high volume and overall impact on the hospital. The 
department chosen for the research was the Department of Family Practice and 


Community Medicine (DFPCM). The DFPCM is one of the 13 major departments 





within SBHACH and serves nearly 53 percent of the hospital’s patients. An additional 
motivation for limiting the scope of the research was the increased depth of the 
analysis and design of an information system that would otherwise be possible. 

In addition to the direct study of the DFPCM, it was necessary to conduct 
research in the many supporting units which influence the department’s overall ability 
to function. The following support divisions were contacted during the course of 
research: 

* Resource Management Division 

* Information Management Division 
* Clinical Support Division 

* Department of Nursing 

* Logistics Division 

* Personnel Division 


e Patient Administration Division 


D. METHODS AND ORGANIZATION 

The thesis research followed the information systems development life cycle 
described in the first two sections of Chapter II. Chapter II discusses the theory of 
information systems and the analysis and design of such systems. The last section of 
Chapter II introduces the application of information systems to health care. Research 
was conducted to discover the history, current status, and future of hospital information 
systems (HISs) and the critical nature of these specialized systems. 

The DFPCM organization and functions are described in detail in the first section 


of Chapter III. Section 2 of Chapter II! discusses the results of the current systems 


analysis. Data Flow Diagrams (DFDs) are introduced in Chapter Ill. DFDs 
diagrammatically portray the current information systems within the DFPCM. 

Chapter IV covers the requirements for improving the existing information 
systems within the DFPCM and how these improvements can be accomplished using 
an automated information management system. The findings in Chapter IV are a direct 
result of the analysis conducted in Chapter III and described what is necessary for the 
information system to meet the needs of the department managers. 

The detailed systems requirements analysis is presented in Chapter V, 
incorporating the functional requirements and alternatives selected in the previous 
chapters. User Concept Diagrams (UCDs) are introduced in Chapter V to 
diagrammatically portray the proposed information systems for the DFPCM. The 
requirements analysis, as described in the chapter, is for the DFPCM alone. This 
analysis can be used to design and implement a management information system for 
this department, or with additional study, may be expandable to other clinics within the 
hospital. 

Conclusions and recommendations resulting from this thesis are given in Chapter 


VI. Chapter VI also suggests directions for further research work. 


Il. INFORMATION SYSTEMS 


A. INTRODUCTION 

This chapter introduces the concepts of an information system and the systems 
development process and discusses the impact of information systems within a hospital 
environment. 

Section B, System Design Concepts, describes the information systems 
development methodologies used in the thesis to design the information system for the 
Department of Family Practice and Community Medicine. The process of selecting the 
most appropriate system development methodology(ies) is also examined. 

Section C, Hospital Information Systems (HISs), describes the critical nature of 
the hospital organization and it’s impact on the role of information systems within the 
hospital environment, both historically and in the near future. Also presented in 


Section C is a description of the information systems currently used at SBHACH. 


B. SYSTEM'S DESIGN CONCEPTS 

An information System has been described as a collection of human, 
computerized, and mechanical agents that work together to acquire, produce, handle, 
store, use, and disseminate information (Lockeman, 1986, p. 617). Information systems 
are meant to support the day to day operations, management, and decision making 
needs of an organization. An effective information system does not necessarily have 
to be automated. Information systems exist, with or without automation, because 


workers within the organization require some sort of a system to collect, process, and 


exchange the information they need. When automation is deemed necessary and 
properly designed, it can provide the organization with an increase in both the 
efficiency and effectiveness of operations. (Whitten, Bently, and Ho, 1986, p. 40) 

There are four important considerations in the development of an effective 
information system. First and foremost, the system must be designed to serve the 
needs of the users. The analyst has a responsibility to provide the user with a product 
that is both useful and correct. Secondly, the analyst should understand the 
organization's mission to build the system to effectively support that mission. Thirdly, 
information systems provide one or more of the three information functions depicted 
in Table I. The analyst must determine which of these functions the system should 
support and how the information system will fit within the organization to fulfill those 
functions. Lastly, the system's components, as depicted in Figure 1, should be 
designed to harmoniously work together to support the system's intended purpose 
within the organization. (Whitten, Bently, and Ho, 1986, p. 692) This requires the 
analyst to systematically analyze the data inputs, data flows, processes, and information 
outputs. (Kendall and Kendall, 1988, p. 6) 


Table I. INFORMATION FUNCTIONS 


Data Processing Systems 
Processes large amounts of data for routine organization 
transactions. 


Management Information Systems 
Provides periodic reports for planning, control and decision making. 


Decision Support Systems 
Supports decision makers by providing information on demand. 
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e Computer equipment or Hardware. Information systems may include a variety of hardware 
components, including copiers, calculators, and computer systems. 


e Computer Programs or Software. A system is a mixture of programs that elther control the 
computer or provide applications to the users. 


* Users (Knowledge workers) are the most vital part of the information system's components. 
They are the central theme in any design methodology. 


e Methods and Procedures. Methods refer to how the system works whereas procedures 
describe how to perform the job and how to make decisions. 


e Data Storage. This is a fundamental component of the system. This is the raw data that must 
be accessed to process into useful information. 


e Internal Controls. Feedback and control are system concepts that must be added to any 
system to ensure its proper operation. 


Figure 1. Information System Components (Whitten, Bently, and Ho, 1986, p. 692) 





Prior to attempting the design of an information system, the systems analyst 
must choose a design methodology which will best meet his or her needs and the 
user’s needs. This selection process and a description of the methodology used in this 
thesis is described in the following sections. 

1. Systems Development Life Cycle Methodology 

System development in the late 1960s' was often behind schedule, over 
budget, expensive, and poorly suited to the users’ requirements. As a result, the early 
system designers developed a set of structured methodologies to make the development 
process more orderly and manageable. The emergence of structured methodologies 
provided the analyst with a welcome escape from the haphazard approaches used to 
develop the requirements, specifications, and programs used in the early design models 
(Ceri, 1982, p. 208). 

As the structured approaches became accepted as a viable systems design 
alternative, more analysts began to perceive that the structured methodology could even 
be further improved with the inclusion of a life cycle within the model. This enhanced 
structured approach, dubbed the Systems Development Life Cycle, was used by these 
analysts to bring together all of the already proven systems design techniques with the 
successful project management techniques. This system development life cycle 
methodology emerged as the most preferred method of all of the system design 


methodologies. (Wassermann, 1984, p. 44) 


' This continues to be the case in the eighties. 





Figure 2 portrays the Systems Development Life Cycle methodology. This 
approach provided several significant advantages over the non-structured approaches and 
the early forms of the structured methodologies. This design approach gave the systems 
analyst a better understanding of the user's requirements while the increasing the user's 
comprehension and participation in the design process. (Willis, Huston, and d'Ouville, 
1988, p. 56) Users also tended to be a lot more satisfied with the final outcome of a 
system designed using this methodology. Information systems designed using this 
methodology were also found to be more flexible and maintainable then the early 
approaches. (Sumner and Sitek, 1986, p. 235) 

As Figure 2 shows, the life cycle begins with a project development request. 
Before a more detailed systems study is started, the systems analyst surveys the 
problem, opportunity, or directive that initiated the request. This survey is used to 
determine whether or not significant resources should be committed to the project. If 
the system development is approved, the development enters the first major phase of 
the SDLC, the study phase. The goal of the study phase is to educate the analyst about 
the current system, thus allowing the causes and effects of the problems to be 
discovered. This type of analysis is presented in Chapter III of this thesis. 

The next phase, the requirements phase, is the most critical of the life cycle 
phases because it provides the foundation for all subsequent phases (Willis, Huston, and 
d'Ouville, 1988, p. 56). This phase is concerned with the analyst understanding the 


problems found in the study phase and describing them in terms of the activities, data, 


information flows, relationships, and system constraints necessary to solve the problem 


(Ceri, 1982, p. 205). This type of analysis is presented in Chapters IV and V of this 


thesis. 
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Figure 2. Systems Development Life Cycle. 
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The evaluation phase looks at how the new system should be developed. The 
analyst must seek out all possible solutions to the problem and generate a set of 
alternative proposals to solve the problem. Each alternative is then evaluated on 
technical, operational, and economic feasibility. The outcome of this phase should be 
a technically feasible solution. (Whitten, Bently, and Ho, 1986, p. 149) 

If this solution calls for new hardware or software, the selection phase 
becomes necessary. During the selection phase, the analyst determines which system 
specifications are important for the equipment or software required for the new system. 
Proposals are then developed and sent to vendors. Once the vendors’ proposals are 
returned, the systems analyst selects the hardware and software configurations that best 
meets the project’s needs at the most reasonable cost. (Whitten, Bently, and Ho, 1986, 
p. 151) 

Given the user requirements, a feasible solution, and the hardware or 
software configurations from the selection phase, the analyst can now design and 
construct the information system. Computer outputs are normally designed first, 
followed by files/databases, and subsequently the user inputs and terminal dialogues. 
The design phase is where system controls, as implemented in methods and procedures, 
first enter the developmental life cycle. The deliverable of this phase is the completed 
design specification and the preliminary procedures necessary for the construction of 
the new system. The construction and design phases are frequently the most time 


consuming and tedious phases, particularly if the requirements are incomplete or do not 
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reflect the actual user’s requirements. Finally the system is delivered, the users are 
trained, and the system enters the maintenance phase. (Whitten, Bently, and Ho, 1986, 
pp. 151-155) 

Throughout the various phases, the analyst is collecting facts, documenting 
the system, presenting ideas, and reevaluating the feasibility of the system. All of the 
phases of the system development life cycle are not discreet and distinct phases. Figure 
3 illustrates how each phase can overlap within the life cycle. (Whitten, Bently, and 
Ho, 1986, p. 157) As a life cycle model should indicate, the process will begin again 
as new project requests are generated, the organization evolves, or the system once 


again fails to meet the user's requirements. 


Activity 


Survey the Situation 


Study the Current System AAA 
Define User Requirements A A 
Evaluate Alternative Solutions gne 
Select New Computer 
Equipment and Software ——— 
Design the New System ——— 
Construct the New System eee 
Deliver the New System bel 


12 3.41 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 
Week 


Figure 3. Overlap Opportunities within the Systems Development Life Cycle. (Whitten, 
Bently, and Ho, 1986, p. 157) 
In spite of the large number of structured methodologies available, this type 


of systems analysis is not widely used (Sumner and Sitek, 1986, p. 235). Today, only 


about ten percent of the data processing organizations in North America practice 
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structured techniques in a disciplined fashion even though 90% of the community is 
at least superficially familiar with the basic concepts (Yourdon, 1986, p. 133). 

Prior to selecting the use of one of these methodologies in our thesis, a 
closer look was taken to determine why these methodologies, so often taught at 
universities, were not being used. Yourdon explains that there are many reasons for this 
reversal in the attitudes toward structured analysis. He felt that the primary reason for 
this reversal was the frustration of analysts over the amount of manual labor required 
to develop systems using the structured methodologies. Analysts in a real business 
environment did not have the time to do the time consuming requirements 
documentation necessary for the requirements analysis when there was a large backlog 
of projects awaiting development. The analysts also became increasingly frustrated 
with the inability to apply these methodologies to complex, real-time systems. 
(Yourdon, 1986, p. 133) Additionally, many systems analysts were not trained in the 
use Of the methodologies and tools and were unsure as to which tools could be 
effectively used within the phases of the life cycle (Ceri, 1982, p. 208). One of the 
major reasons for this reversal of attitudes was the development of the prototyping 
methodologies discussed in the following section. Many analysts were lured away 
from the structured approaches to systems development by the promise that prototyping 
could be used to interactively design and progressively tune the systems design without 
the rigorous requirements of the structured approaches (Ceri, 1982, p. 208). 

Too often, even though the structured techniques were used, the end result 
was a better design that still did not meet the users’ needs. Because of the time lag 


between the analysis and implementation phases in the structured methodology, the 
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users’ environment changed even after the system’s requirements were set in the 
requirements and design phases. The users also had difficulty communicating their 
requirements to the analyst. Senn points out “users can point to features they like or 
dislike in an existing system more easily than they can describe them in an imaginary 
or proposed system." (Senn, 1987, p. 611) These observations led to the conclusion 
that a better design methodology was needed to meet system development requirements. 
2. Prototyping Methodologies 

Information systems analysts saw the need for an improved design method. 
They felt that any systems development approach required the concurrent learning of 
both the analyst and the users. During the requirements phase, the major functions of 
the analyst are to help users formalize their tasks and decision processes, ensure that 
the users learn the analyst’s modeling techniques, and help the users understand the 
scope of the project (Cerveny, 1987, p.98). The structured methodologies simply did 
not fulfill this requirement. Recent developments in computer technology, primarily the 
introduction of user friendly code generators, allowed the systems analysts to develop 
a better approach to the systems development process. This new approach, prototyping, 
was designed to alleviate some of the problems that concerned the systems analysts 
about the traditional approaches. (Willis, Huston, and d’Ouville, 1988, p. 57) 

The concept of prototyping is not new. In engineering, prototyping has long 
been a standard for developing and testing new products and systems (Scharer, 1983, 
p. 60). Prototyping was not designed to replace the systems development life cycle. 
Instead, prototyping enhances the life cycle by promoting the mutual leaming processes 


between the analyst and user (Cerveny, 1987, p. 98, 103). Prototyping uses the power 
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of demonstration to enable the user and the analyst to literally see their specification 


in action (Scharer, 1983, p. 60). Prototyping has the following significant advantages 


over the traditional structured methodologies: 


Gets the user more actively involved in design and development. 


Provides the user with a tangible means of comprehending and evaluating the 
proposed system. 


Achieves more meaningful user feedback in terms of their needs and 
requirements. 


Develops better relationships between systems analysts and user groups. 


Results in fewer post implementation changes, resulting in lower maintenance 
costs. (Kroenke, 1987, p. 157) 


The system that had been prototyped could be developed in one quarter of the 
time required of the structured methodologies. (Willis, Huston, and d’Ouville, 
1988, p. 58) (Harrison, 1985) 


The main benefit of using a prototype methodology is the development of 


an information system that more closely fits the needs of the organization. Prototyping 


also reduces the risks involved with the development cycle by getting the system into 


operation quickly and keeping the system simple. (Cerveny, 1987, p.57) Prototyping 


is not superior to the traditional methods in all cases. Table II depicts the factors that 


favor either the traditional or prototype methodologies. 


Figure 4 depicts the modified systems development life cycle where 


prototyping techniques have been integrated into the life cycle. After the users have 


specified their needs, the analyst can then demonstrate how the proposed system can 


meet those needs. Design by prototyping consolidates the requirements definition, 


design, and construction stages of the typical system development life cycle discussed 
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earlier. These three activities take up approximately 60 percent of the manhours 
required for a system study. Consequently, prototyping yields a net saving in effort 
when it is utilized in the design of information systems. (Willis, Huston, and d’Ouville, 
1988, p. 58) 


Table II. FACTORS FAVORING ALTERNATIVE DEVELOPMENT METHODS 
(Willis, Huston, and d'Ouville, 1988, p. 58) 


Project Characteristics of Alternative Development Methods 


Factors Favoring Traditional Systems Development 
* Data needs are clearly defined. 
e Systems have long life expectancy. 
e Tight controls are required. 
* Development risks are clearly defined. 
e Essential system features are known in advance. 
* Operational characteristics are well understood. 


Factors Favoring Prototyping 
* User requirements are uncertain. 
* Procedure changes are extensive. 
* User environment is volatile. 
e System has relatively shor life expectancy. 
e System needs to be operational in short period of time. 
e Changes in specifications are anticipated. 


The construction of a prototype model requires that the systems analyst 
follow the six basic steps listed in Table III and described below. 


Table III. STEPS IN PROTOTYPE DEVELOPMENT (Willis, Huston, and d’Ouville, 
1988, p. 57) 


Prototyping Design Steps 


Select an appropriate application. 

Identify basic needs. 

Develop the working model. 

Refine the model and system interface characteristics. 
Implement revisions and enhancements. 

Prepare prototype documentation and plan for development. 
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Figure 4. Prototyping Systems Development Life Cycle 
a. Step One: Select Appropriate Application 
The first consideration for the systems analyst is to determine if the 
system under development favors the prototyping design methodology. This 
methodology is not superior to the structured approaches in all cases. The analyst takes 
into consideration all the factors listed in Table II, Factors Favoring Alternative 
Development Methods, the user’s environment, and the availability of prototyping tools 
to determine if the system can best be developed with the prototyping approach. 


(Willis, Huston, and d’Ouville, 1988, p. 58) 
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The environment within the DFPCM favored the use of prototyping for 
the following reasons: 
* Uncertain user requirements. 


* The environment was particularly unstable, subject to wide swings of personnel 
availability and work procedures. 


* The new system is needed immediately to meet the department's expanding 
role within the hospital. 


* The system was expected to have a relatively short life cycle. 


« Numerous changes were expected in the specifications, as reports, procedures, 
and requirements for information appeared to be changing daily. 


b. Step Two: Identify Basic Needs 
The second step in prototyping involves getting a better understanding 
of the problem or opportunity that was developed in the study phase. (Willis, Huston, 
and d'Ouville, 1988, p. 59) The goal of this step is to develop enough of an 
understanding of the problem to enable the design and construction of the initial 
prototype model (Boar, 1984, p. 67). 
c. Step Three: Develop Working Model 
The purpose of this step is to build the initial version of the prototype. 
Screens and documents layout are defined, data records are specified, and other model 
characteristics are established (Willis, Huston, and d’Ouville, 1988, p. 59). Content, 
not presentation, should be the primary goal of this initial model (Boar, 1984, p. 69) 
The analyst’s intent, in this stage, is not to come up with the perfect model but to 
develop a model that best matches the user’s view of the problem. Quality is critical. 


If the model is incomplete, it results in a poor foundation for the rest of the 
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development cycle. The target time for delivery of the initial model, depending on the 
prototype environment, should be three to six weeks. (Boar, 1984, p. 69) 
d. Step Four: Refine Model and System Interface Characteristics 
In this step, the system is refined so that each of the initial prototypes 
tested earlier are now required to work together. The analyst's goal in this step is to 
immediately test new ideas to see what refinements will satisfy the majority of the 
users. Ás users review this refined prototype and changes are made, the important 
changes are documented for later reference. (Willis, Huston, and d'Ouville, 1988, p. 59) 
e. Step Five: Implement Revisions and Enhancements 
The objective of this step is to allow the users to review the 
information system in as complete a context as possible. This review occurs after all 
the changes and enhancements have been implemented and serves as the final 
evaluation of the information system in the eyes of the user. (Willis, Huston, and 
d'Ouville, 1988, p. 59) Except for minor problems, the prototype is essentially 
complete. 


f. Step Six: Prepare Prototype Documentation and Plan for 
Development 


This stage of the prototype cycle involves the completion of the 
documentation for the system and the determination of the fate of the prototype. The 
format and the extent of the documentation rests largely with the project manager. The 
final decision is made conceming how the prototype should be used in the new system. 


At this stage the analyst can go in three directions with the prototype. 
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e If the implementation of this prototype is too expensive or infeasible, the 
system can be abandoned. 


¢ Depending on the analyst’s prototyping development tools, the prototype could 
actually be implemented directly. 


* As is the case with this thesis, the prototype could be used simply as a step 
to another stage of the development process. The prototype provides the 
analyst with a knowledge base for the design of the new system. (Willis, 
Huston, and d’Ouville, 1988, p. 59) 

The successful prototype clearly enhances the traditional approaches. It 
is usually considerably cheaper, less risky, and conveniently keeps the system simple 
from the user’s perspective. It’s primary advantage is that it allows the user to see the 


application in its operational context and determine if the current design fits his or her 


needs. (Willis, Huston, and d’Ouville, 1988, p.60) 


C. HOSPITAL INFORMATION SYSTEMS (HIS) 
1. The Critical Nature of Hospital Information Systems 

The health care delivery system in a hospital environment is generally 
viewed as an industry. This industry has seen major changes in recent decades due to 
breakthroughs in medicine and technology. The cost of health care nationwide has 
increased more than tenfold since 1950 to over $120 billion making health care one 
of this nation’s largest industries (Rakich and Darr, 1978, p. 1). In addition to the 
major changes taking place in the health care industry, the very nature of health care 
delivery creates a complex organization for the hospital administrator. Rakich and Darr 
suggest the hospital is one of the most complex organizations in existence based on the 


characteristics discussed below. 
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* There is a wide diversity of objectives and goals for different personnel and 
subsystems (e.g., patient care, education, research, accommodations, 
administration). 


* The diversity of personnel ranges from highly skilled physicians and 
administrators to unskilled laborers. 


e The hospital is in continual operation. 
* Hospitals deal with life and death decisions. 


* Measuring the major product (patient care) is difficult. (Rakich and Darr, 1978, 
p. 1) 


These often conflicting attributes can cause problems for hospital decision 
makers. A dichotomy is created by the conflicting goals of the hospital’s two 
components, management and operations, and becomes most evident and important in 
an environment where societal pressures and legal implications concerning ethical 
behavior are greatest. The non-medical management component (sometimes referred to 
as “bean counters’) measures efficiency, 1.e., the maximum amount of output (hospital 
Services) for a given input (cost). The medical component (health care providers) 
measures performance by the quality of care provided to the patient (Longest, 1978, 
p. 125). This difference of purpose and objective will impact the manner in which 
information is managed and used in the hospital environment. Figure 5 is a humorous 
portrayal of the conflicts which exist between doctors and administrators when 
considering the use of computer resources (Covvey and McAlister, 1980, p. 141). 
However, the consequences of such conflicts are quite serious and play an important 
role in the potential effectiveness of a hospital information system (HIS). 

Another factor influencing the HIS is the complexity of the relationship 


between the doctor and the patient. The ethics and responsibilities involved make 
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doctors wary of new technologies and methods unless the benefits to the patients can 


be proven. (Safir, 1978, p. 98) 
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CLINICAL 
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Figure 5. Conflicts 

The complexity and significance of health care organizations described in the 
preceding paragraphs creates a critical environment for a HIS. The conflicts which exist 
have affected the use and advancement of HISs throughout their life span and continue 
to influence the way in which hospital personnel view the quality and effectiveness of 
the HIS. (Safir, 1978, p. 98) 

2. HIS Environmental Overview 

Early hospital information systems were developed primarily to support 

hospital administration. Hospitals applied computer resources in conventional ways for 


accounting and other business related administration. Computers were also used in 
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medical research but were not generally considered suitable for directly supporting the 
medical care given to patients. 

Figure 6 (Covvey and McAlister, 1980, p. 137) shows three main areas 
where medical computing can be applied in a hospital environment. The two large 
circles represent the more traditional applications of computers in health care, 
administration and research. The intersection of these circles represents the area of 
medical computing related to the care provided to patients. This area overlaps both 
medical research computing and administrative computing and is affected by the 
conflicting objectives of doctors and managers discussed earlier. We targeted this area 
of medical computing in our research and found a tremendous lag in the computer 


technology applied to medical care delivery. 


Hospital 
administration Medical 
computing service 
computing 


Clinical 
computing 


Purely medical 
research computing 


Purely business 





Figure 6. Three Areas of Medical Computing 
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Experts in both the medical and computer fields began to recognize the 
medical computing lag in the mid-1970s and have made concerted efforts to catch up. 
A Symposium on Computer Applications in Medical Care (SCAMC) has met annually 
since 1976. In 1978, hearings were held before the Subcommittee on Domestic and 
International Scientific Planning, Analysis and Cooperation to discuss the topic of 
computers in health care. The reasons for the medical computing lag can be traced 
back to the critical nature of the HIS introduced in the previous section. In 1978, 
Aran Safir M.D. wrote: 

..the complexity that characterizes human interactions is perhaps nowhere better 
demonstrated than in the relationship of doctor and patient. Representing such 
complex human interactions effectively within the computer is exceedingly 
difficult. (Safir, 1978, p. 98). 

In 1980, Covvey and McAlister found it was rare for hospitals to devote a 
portion of its budget to data processing equivalent to that spent by most other 
industries of comparable size (Covvey and McAlister, 1980, p. vi). The following 
barriers to medical computing were suggested in 1985 by Bonnie Kaplan, Ph.D. at the 
annual SCAMC symposium (Kaplan, 1985, p. 400): 

* Lack of funding, technology, staffing, training, and effort. 


* Poor management including difficulties of interdisciplinary teams, planning and 
approach, and lack of attention to human factors and methodologies. 


* Difficulty of translating medical knowledge into a form suitable for computing. 
e Institutional constraints and physician resistance. 
These barriers will exist to some degree in every organization. Many 


hospitals are attempting to hurdle the barriers through improved communication and 
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cooperation between doctors and administrators. Large hospitals are moving toward a 
HIS which integrates administrative, research, and medical service computing into one 
complete system. An example of an integrated HIS is the University Hospital 
Information System (UHIS), introduced in 1980 when the University Hospital at State 
University of New York first opened its doors. UHIS offered a wide range of patient 
care services including registration, medical records, automated lab data, quality control, 
pharmacy, radiology and nursing (Vegoda and Dyro, 1986, p. 261). 

The medical computing future shows a trend toward increased integration of 
hospital information system functions like that described in the UHIS. The Yale-New 
Haven Hospital began implementing the Patient Care Support System (PCSS) in 1986. 
PCSS is expected to take several years to implement. When complete, PCSS is 
expected to improve the quality of care rendered to patients by allowing physicians to 
more efficiently and accurately order tests, lab work, and prescriptions. Medical record 
tracking and results reporting is also expected to improve (Sadock, 1986, p. 114). 

The Department of Defense’s answer to an integrated HIS is the Composite 
Health Care System (CHCS) scheduled for completion in 1991. The objectives for 
CHCS include: "improving the quality of patient care, increasing the efficiency of 
operations, increasing the accuracy and availability of information, and providing 
standardized, but flexible support." (Regional Training Conference Manual, 1988, p. 
135). In 1988, a Regional Training Conference was held in Monterey, CA to update 
attending medical professionals on military and other government medical information 
System initiatives (Regional Training Conference Manual, 1988). One of the topics 


covered at the conference was the planned implementation of CHCS. The following 
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patient care benefits of the CHCS were cited (Regional Training Conference Manual, 
1988, p. 140): 

* Improved quality of care. 

e Reduced time spent handling information. 

* Improved management control of operations. 

* Increased patient satisfaction. 

* Increased compliance with standards and regulations. 

* Increased service capacity with same staff levels. 

* Improved personnel morale and job satisfaction. 

Doctors and hospital administrators are trying to recover from the medical 
computing lag which has continually plagued the industry. They are beginning to 
realize the importance of quality information for providing high quality patient care. 
Integrated HISs are the future for medical computing and, if properly used, will enable 
the health care industry to provide better quality medical care. 

3. Information Technology at Silas B. Hays Army Community Hospital 

The current information technology at Silas B. Hays Hospital consists of 
three major systems, the Medical Expense and Performance Reporting System 
(MEPRS), the Automated Quality of Care Evaluation Support System (AQCESS), and 
the Computer Stored Ambulatory Record System (COSTARS). These three systems are 
completely independent and are maintained through separate government contracts. No 
attempt has been made to link these information systems into one large database. 
Because of the inherent incompatibility of the systems and the eminent arrival of the 


Composite Health Care System, SBHACH administrators believe it would be cost 
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prohibitive to attempt systems integration at this time. The next three sections describe 
the basic function of each of these systems. 
a. MEPRS 

The purpose of MEPRS is to collect, process, and report to the Health 
Services Command (HSC) all data on the medical workload, staffing, and expenses 
incurred by each workcenter within the hospital (Regional Training Conference, 1988, 
p. 47). Each hospital department maintains various worksheets to record manpower 
utilization and workcenter expenses. Each department reports the hours for clinicians 
(doctors) and non-clinicians (all others) to the MEPRS section, a subdivision of the 
Resource Management Division (RMD). Also recorded are the inpatient bed days and 
the number of outpatient visits for each of the workcenters. This workload information 
is maintained in both the AQCESS and COSTARS systems but because the systems 
are incompatible, the data must be manually extracted from each of the systems for 
entry into the MEPRS system. Direct expense data on such items as electricity and 
water is received from the Fort Ord Finance and Accounting Office and manually 
extracted by the MEPRS personnel and recalculated based on the square footage of 
each departments’ assigned space. This expense information is then manually entered 
into the MEPRS computer. Each month all hospital data is loaded onto a magnetic 
tape and sent to the Health Services Command (HSC) at Fort Sam Houston, Texas. 
The data is used by the HSC for determining funding allotments for Silas B. Hays. 
The information maintained in the MEPRS system is not considered useful to the 
department managers because it is not kept in a format consistent with department 


resource measures. 
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b. AQCESS 

AQCESS was introduced early in 1986 for all Department of Defense 
Hospitals. The primary purpose of the system was to provide a standardized method 
for the collection and reporting of patient and provider information and to assist in 
quality assurance decision making for all military hospitals. AQCESS was intended to 
improve the quality of the information provided to administrators, doctors, and quality 
assurance personnel and to save hospital staff time. Initially implemented with three 
main modules, AQCESS has since been expanded to six modules. All six modules are 
in operation at Silas B. Hays: 

1, Quality Assurance Module 

2. Appointment and Scheduling Module 
3. Medical Services Accounts Module 
4. Clinical Records Module 

5. Registration Module 

6. Emergency Services Module 

The Appointment and Scheduling Module affects each individual 
department the most as it determines the daily workload for each doctor in the 
department. 

The AQCESS system is used to capacity. Although ad hoc reports can 
be obtained by the users of AQCESS, only the system manager in the Information 
Management Division (IMD) currently uses this function. The system is heavily used 
during normal working hours for interactive appointment scheduling and clinical 


records. To help keep system response time low during the day, all AQCESS reports 
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are generated at night using batch processing. The AQCESS modules produce many 
reports which show hospital operations and performance in many areas. Statistical 
reports on workload, productivity, and appointment scheduling histories are just a few 
of the topics covered. 
c. COSTARS 

The COSTAR System is unique to the Family Practice Clinic at Silas 
B. Hays Hospital. This system receives, records, and retrieves administrative and 
medical information for the active duty families enrolled in the Family Practice 
Program (Libra Technology, 1982, p. 2). This system was actually a prototype system 
introduced in 1982 and initially had the five main functions described below: 


* Registration - This function allows patients to be enrolled in the Family 
Practice Program. 


* Appointment and Scheduling - This function allows the COSTARS data entry 
clerk to book, cancel, or view appointments. It also prints daily schedules and 
appointment lists and produces a pull list for the medical records department 
indicating which patients records will be required for the following day's 
appointments. 


* Medical Records - This functions maintains a history of a patient examination, 
including administrative, physical, diagnostic and procedural data. 


* Pharmacy Orders - This function was intended to provide full pharmacy 
support by allowing prescription orders to be automatically forwarded to the 
pharmacy. Records on pharmaceutical history were also to be kept for the 
patients. Currently, only prescription refills are managed by this system. 


* Laboratory Orders - This function permits physician orders for lab work to 
be automatically sent to the lab before the patient arrives. Results are also 
entered and a daily report is sent to the physician showing the patient and the 
results of the lab tests ordered for that patient. 

Like AQCESS, the COSTARS system maintains a large data base and 


is capable of producing many reports. COSTARS also accepts ad hoc queries but none 
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are currently being used. The pharmacy and laboratory functions offer capabilities not 
found in AQCESS. As with the other major systems, we believe this system is not 
being exploited to full advantage. This system, and the potential benefits of the data 
maintained within it, are discussed further in subsequent chapters. 

In addition to the three major information systems discussed above, 
Silas B. Hays makes extensive use of microcomputers for office automation and 
individual data processing functions. These computers are not currently networked nor 
is there any standardization of software or procedures. 

The current information systems available at Silas B. Hays Hospital 
are cumbersome and cannot be integrated to provided timely, reliable, and useful 
information to hospital decision makers. The lack of integration is seen as a major 
problem by many hospital personnel and, until the CHCS comes on line, stop-gap 
measures are being used to fill the void and provide the best information available 
with the limited resources. 

The remainder of this thesis describes how one department, the 
Department of Family Practice and Community Medicine (DFPCM), uses the current 
information systems available at SBHACH. Also examined is the need for an improved 
system and how these improvements might be realized through the use of a responsive 


microcomputer-based information system. 
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IM. CURRENT SYSTEMS ANALYSIS 


A. INTRODUCTION 

Chapter II introduced information systems development methodologies and the 
application of information systems within a hospital environment. This chapter 
describes the current information systems in the Department of Family Practice and 
Community Medicine, using the development principles discussed in Chapter II. This 
chapter introduces data flow diagrams as a pictorial way to represent the existing 
information system and presents data flow diagrams and narrative descriptions for the 


department's information system. 


B. THE DEPARTMENT OF FAMILY PRACTICE AND COMMUNITY 
MEDICINE 


Early in 1988, Health Services Command approved a reorganization for Silas B. 
Hays Hospital which combined the Department of Family Practice with the Department 
of Primary Care and Community Medicine, creating the Department of Family Practice 
and Community Medicine (DFPCM). This new department is the hospitals largest and 
most diverse in terms of both the services it provides and it's overall affect on the 
hospital. Figure 7 is the department's organization chart. The department has three 
general service areas: Family Practice and Residency, Primary Care, and Consolidated 
Troop and Family Member Services. These are further divided into specialized clinics 
(sometimes referred to as sections) as shown in the chart. All of these clinics are 


outpatient oriented and are literally the gateways to all other hospital services (e.g., 
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Figure 7. Organizational Chart for DFPCM 


pharmacy, lab, and specialized medical departments). The DFPCM affects every aspect 
of the hospital: every patient treated at Silas B. Hays must first be seen by a doctor 
working in one of the DFPCM clinics. The mission of the DFPCM, as stated in the 
Health Services Command Regulation 10-1, is "to provide diagnosis, care, and treatment 
of all patients commensurate with the highest standards of quality." (HSC Reg 10-1, 
1987, p. 3-1) The task of accomplishing this mission is not nearly as simple as the 
mission statement itself. 

The size of the department, the volume of work done, and the impact on overall 
hospital resources combine to create a highly visible, management challenge. The 


Chief of the DFPCM (currently a Lieutenant Colonel) is responsible for meeting this 
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challenge. The resources he commands include over 150 people and an annual budget 
of nearly half a million dollars. In addition, there are five separate service locations, 
one of which is 100 miles from the main hospital (Fort Hunter Liggett). Unfortunately, 
these resources are limited compared with the task at hand. Since his time is 
extremely valuable, the information he gets should be summary in nature in order that 
he not be overwhelmed with meaningless data, and yet at the same time, complete 
enough to allow him to make informed, confident decisions. All of these factors must 
be considered when designing an information system for use by the Chief of the 
DFPCM. 

Initial interviews with the Department Chief allowed us to identify those 
management areas which demand the greatest attention and for which he requires the 
best possible information. These areas fell into the following seven broad categories: 

e Fiscal Resources. 
e Material Resources. 
e Personnel and Scheduling. 
e Productivity. 
e Patient Satisfaction. 
e Medical Procedure Suspense Information. 
e Patient Check-In and Records Procedures. 
The last two areas were determined to be beyond the scope of this thesis because 


of time constraints and the inherent size and complexity of the projects themselves. 
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The Department Chief agreed with our decision and prioritized the remaining five areas 
as shown below: 

* Fiscal Resources. 

* Material Resources. 

* Personnel and Scheduling. 

e Patient Satisfaction. 

e Productivity. 
The remainder of this thesis describes the research into each of these areas and the 
requirements for an information system which would serve the Department Chief in 
making management decisions concerning these key areas. 

The five major areas listed above were divided into the following six specific 

systems: 

* Budget System. 

* Equipment System. 

* Personnel System. 

e Scheduling System. 

e Patient Satisfaction System. 

e Productivity System. 

The following section describes the six existing information systems listed above 

(with diagrams and written narrative) and how information is gathered, stored, and 
presented for decision making. As described in Chapter IT, the current system should 


be well understood before any attempt 1s made to improve any part of it. Subsequent 
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chapters discuss where and why improvements are needed and how those improvements 


can be achieved through system redesign and automation. 


C. DATA FLOW DIAGRAMS 

In the preliminary description of the information system within the DFPCM, we 
used Data Flow Diagrams (DFDs) to represent the current system to department 
personnel. The Data Flow Diagram enables the designer to describe the existing 
system or the proposed new system at a logical level without considering the physical 
environment in which the data flows (e.g., telephone calls, mail, etc.) or the physical 
environment in which the data is stored (e.g., card file, microfiche, disk, floppy disk, 
or tape). (Atkas, 1987, p. 57) The DFD describes the system as a network of 
processes (subsystems) connected to each other and/or to data stores, sources and sinks. 
(Atkas, 1987, p. 58) The basic symbols used in the DFD’s are described below. 


* Data Flow. An arrow is used to represent either the flow of information or 
objects. Occurrences of the data flow must contain data. 


* Process. A rounded rectangle represents a process. Processes are work 
performed by people, machines, or computers on incoming data flows to 
produce outgoing data flows. (Whitten, Bently, and Ho, 1986, p. 226) 


e External Entity or Boundary. A square is used to represent an area in 
which data originates or terminates. In essence, the sources and sinks define 
the boundaries of the system. 


e Data Store. An open-ended rectangle represents a store of information or 
objects, irrespective of the storage medium. (Atkas, 1987, p. 59) 
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The components of the information system correspond to the DFD symbols as follows 


(Whitten, Bently, and Ho, 1986, p. 234): 


Information System Component DFD Symbol 

Data (Input) Data Flow 
Information (Output) Data Flow Users 
Entity/Process Methods/Procedures 
Process Data Storage Data Store 
Computer Equipment Process/Data Store 
Computer Programs Process 


To achieve clarity, DFD”s are prepared at several levels. The highest level DFD 
is the "context diagram," which merely shows the boundaries of the system under 
study. The processes are further decomposed as necessary into lower level diagrams. 
(Atkas, 1987, p. 68). The following sections use DFD's to illustrate the six current 
information systems. 

l. Budget Svstem (see DFD, Figure 8). 

The Resource Management Division (RMD) receives the hospital's budget 
from the Health Services Command on an annual basis via the MED 304 report. 
RMD divides this budget into quarterly budget targets for each department and 
distributes the budget allocations at the beginning of each quarter. The department 
Non-commissioned Officer in Charge (NCOIC) (currently a Master Sergeant) is the 
principle administrator of all incoming budgetary information. He serves both as the 


Department Chief’s budget administrator and the clinics central point of contact on all 
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budgetary matters. This practice of using the NCOIC as the monitor appears to be 
common practice throughout the hospital. 

Once the department’s budget is received from RMD it is allocated by the 
NCOIC into 16 separate accounts. The 16 budget accounts reflect the current 
organizational structure with a few exceptions required by funding needs. The 16 
sections are listed below: 


e Primary Care. This is an overall budget category for any department wide 
requirements. 


e Family Practice Clinic. This is the eighth floor Family Practice clinic at the 
hospital. 


e CTMC-Family Practice. This is the Family Practice clinic operated at the 
CTMC. 


« Emergency Medical Services. This is the emergency room excluding the 
ambulance section requirements. 


e Ambulance Section. Supply budget for the ambulance section which is a 
subsection of the emergency room. 


e Flight Surgeon Office. 


* General Outpatient Clinic. Serves walk-in patients and active duty sick call 
in the Hospital. 


e Presidio of Monterey-Health Clinic. Though the POM clinic is run by 
PRIMUS, the department assigns a doctor as liaison to handle sickcall and 
official military matters for which it receives department funds. 


e Consolidated Troop Medical Clinic (CTMC). Medical care for 7th Light 
Infantry Division personnel. 


* Battalion Aid Station. This money is provided to the Division Medical 
Supply Office to reimburse medical supplies used by the battalion aid stations 
throughout the division. 


e Fort Hunter Liggett Clinic. 


ay 


e CTMC (Pathology). Funds in this category pay for supplies needed by the 
pathology section located at the CTMC. 


e CTMC (Radiology). Funds in this category pay for supplies needed by the 
X-Ray section at the CTMC. 


e CTMC (Pharmacy). Funds in this category pay for supplies needed by the 
Pharmacy Section at the CTMC. 


¢ CTMC (Immunization). Funds in this category pay for immunization 
supplies for the CTMC. 


e Battalion Aid Station (Immunization). Funds in this category pay for 
immunization supplies used by the battalion aid stations. 


Each section prepares requisitions and monitors its expenditures in its own 
Document Control/Funds Control register (DC/FC). This document serves as a record 
for items ordered and an indicator of the account’s remaining funds once the supplies 
are received. The DC/FC register is currently maintained manually in each clinic’s 
supply section. One important location for the expenditure of supply dollars is the Self 
Service Supply Center (SSSC). The SSSC is a self service supply point for certain 
office, medical and computer supplies. These supplies are charged against the 
individual section’s account and are usually recorded on a weekly recap basis by an 
entry into the DC/FC register. These expenditures are reconciled on a weekly basis 
with the Detailed Obligation Report (DOR). This report confirms correct obligation 
amounts and recorded orders. Four copies of the DOR are received weekly from RMD 
in microfiche form. The four copies are distributed to the CTMC, Fort Hunter Liggett 
clinic, the main Familv Practice clinic. and the department NCOIC. There are a 
limited amount of DOR’s available, so every section cannot receive it’s own Copy. 


This shortage is caused by a number of microfiches actually delivered to RMD. 


38 


[ DISTRIBUTE, <Departeent DOR’ ) 
| DOR 5 


——MM9Ó 


. Hespital’s DOR > f 
í RESOURCE (Expenditures by APC) 


A 
| MANAGEMENT | p PREPARE | cionth End Rpt) 


DIVISION MONTH END |) 
(Hosp Budget? REFORT DEPARTMENT 
ACDIC 







\ j 
\ 
: tay aM 
\ DEPARTMENT 
BUDGET (Dept Budget > 
(Supply Targets? PREF ARE 
S| SECTION 
DIVISION BUDGE T 
(Supply Requisition) PREFARE | «BUDGET STATUS) 
BUDGET 
(Section Budget? (MONTH END REFORT> | STATUS \ 
FAMILY 
(Order Requests? PRACTICE 
(FUNDS AVAILABLE > DEPARTMENT 


CHIEF 





REQUISITION | <Supply Req? 
A SECTIONS 
(17) «FUNDS AVAILABLE? 


(Recorded Obllgation? 


(RIR) / 







DOCUMENT AND E x 
FUND CONTROL ( 2 EH Available> 


REGISTER 
Reconcile 
Docueent 
Register | (Reconciliations) ERN 
DIVISION 
NE 
ES 


Figure 8. Budget System Data Flow Diagram 


( VALIDATED BEAR) 


The NCOIC provides the Department Chief with budget information via 
the department Budget Status Report (see Figure 9). This report is prepared at the 
beginning of the quarter, at the beginning of each month, and on a recap basis at the 
end of each quarter and the Fiscal Year. The Budget Status Report is the department's 
principle source of information on current budget and expenditure status for each of 
the 16 accounts. The report is currently generated using a LOTUS 1-2-3 spreadsheet 


program maintained by the NCOIC. The spreadsheet printout shows expenditures by 
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Figure 9. Department Budget Status Report 
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section, their uncommitted funds and appropriate percentages of expenditures for the 
reporting period. The printout is given to the Chief monthly and maintained by the 
NCOIC in a file on a microcomputer disk. 

Monthly, the NCOIC receives a month-end report from RMD that reflects 
the expenditures by medical and non-medical categories for each of his separate clinics. 
The month-end report is used to update the Budget Status Report for review by the 
Department Chief and the section chiefs. The principle problem with this system 
concems the end of year constraints. As the end of the year approaches, the 
expenditure of funds becomes crucial. The amount that is reflected in the month-end 
report may be several obligations behind the actual expenditures recorded in the 
section's DC/FC register. This requires a direct matching of available funds by 
monitoring the sections through telephonic expenditure reports. 

Quarterly, the Resource Information Report is generated to be used in a 
meeting between the Department Chief and his section chiefs (see Figure 10). This 
report serves as the agenda for the meeting. The primary topic in this meeting 1s the 
projected budget shortfalls for the quarter based on unforeseen requirements. 

On an as needed basis, the Budget and Equipment Analysis and Review 
report (the BEAR) is requested from the section chiefs. This report reflects much the 
same budget information contained in the Resource Information Report but includes 
important information on the status of critical department equipment such as 
replacement or maintenance requirements (discussed below). The BEAR 1s collected 


by the NCOIC for comments and delivered to the Chief for his review. 
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Figure 10. 
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2. Equipment Procurement System (see DFD, Figure 11). 

The equipment requirements for the department are interrelated with the 
budget system described above in that all expenditures for equipment must be budgeted 
and tracked within that system. The department's equipment needs occur in the four 
areas listed below: 

e Durable Equipment. This includes low cost, less than $1000, equipment that 
is used on a day to day basis. This equipment is funded through the normal 
supply budget. 

* Capital Expense Equipment Program (CEEP). Medical equipment that 
costs more than $1000 but less than $5000. The budget for this equipment 
is maintained by RMD. 


e Medical Care Support Equipment (MEDCASE). Equipment that costs more 
than $5000. This budget is maintained by RMD. 


* Computer/Electronic Equipment. Although the cost of this equipment is 
taken out of the department’s budget, the approval to order it comes from 
outside the department (discussed below). 

The primary source of equipment authorizations is the Table of Distribution and 
Allowances (TDA) which shows the equipment authorized to be procured and held by 
each department section. Special medical equipment not included in the TDA must be 
specifically identified and requested by the department. 

Each section identify their equipment requirements by determining equipment 
authorization levels, the equipment currently on hand, the status of equipment on order, 
and the equipment that requires replacement. The sections have numerous sources they 
can use to determine the status of their equipment. The Logistics Division’s Property 


Management Branch maintains property records for all equipment held by each section. 


They also produce reports on the status of equipment on order, the useful life of 


HD PEA 
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equipment on hand, and the number of years the equipment has been extended over its 
defined useful life. The Medical Maintenance Division maintains cumulative status 
reports on the maintenance performed on all medical equipment along with the one- 
time expenditure limit which defines the maximum limit for future repair costs for each 
equipment item. This information is critical in determining if a piece of equipment has 
exceeded its allowed maintenance expense. 

The problem with all of these reports is their relative inaccessibility to the 
sections. The reports are not distributed to the sections and the maintenance reports 
are maintained in the Medical Maintenance building, separate from the hospital. 
Because of these difficulties, not all sections attempt to obtain this information. 
Another major factor affecting the availability of this information is that the reports are 
not divided into sections or departments but maintained on a hospital-wide basis. 

Often, equipment needs are not identified until failure of the old equipment. 
The Department Chief and NCOIC recently created the Budget and Equipment Analysis 
Report (BEAR) to help them plan for equipment expenditures and better manage their 
equipment budget (see Figure 12). This report will be completed by each section on 
an annual basis to identify critical equipment needs. The BEAR report not only 
identifies critical needs but was intended to promote interest in identifying those needs 
in a more timely manner. The sections must identify their replacement requirements 
for the upcoming fiscal year and for four subsequent years. he sections also report the 
requirements for CEEP and MEDCASE items, along with the status of equipment on 


order. 
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Figure 11. Equipment System Data Flow Diagram 


Department Chief, in conjunction with his service chiefs, determines the priorities for 
the department. The appropriate paperwork is completed and forwarded to the RMD 
Logistics Division to await the next hospital wide Program and Budgeting Advisory 
Committee (PBAC). The PBAC consists of key hospital personnel who review and 
prioritize MEDCASE and CEEP requirements for each department. If approved, these 
items go onto a list of prioritized and approved equipment, either MEDCASE or CEEP, 


and await the availability of funds. 
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Currently, there is no consolidated list of the department's needs but each 
section maintains its own list. The only source of consolidated information on 
equipment needs are the quarterly Resource Information Reports, discussed in the 
previous section. 

Needs for electronic and communications equipment are separately identified 
by each section on an Information Capability Request (CAPR). Once the CAPRs are 
approved by the Department Chief, they must be countersigned by the Chief, 
Information Management Division, the Deputy Commander for Clinical Services, and 
eventually by the Directorate of Information Management for Fort Ord (DOIM). Once 
approved, it is the responsibility of the department to obtain the funds and order the 
equipment. 

The Department Chief needs all of this information to plan for equipment 
expenditures. He can use the information provided by his sections to plead his case 
to the hospital administrators who allocate the funding dollars for his department. The 
“out year" information provides him with a projection of future equipment needs and 
helps improve the department budgets. 

3. Personnel System (see DFDs, Figures 13 and 14) 

The DFPCM employs more than 150 people. To effectively manage these 
people, the Department Chief requires personnel information in three main areas: 
authorized positions and vacancies, educational travel funding requirements, and 


personnel leave and temporary duty requests. 
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Each department in the hospital is authorized a certain number of people, 
by position, based on the Table of Distribution and Allowances (FDA). The 
Department NCOIC uses a word processing program to keep a list of all authorized 
positions, both filled and vacant, for the DFPCM. This list contains appropriate TDA 
line numbers and position descriptions plus the personal data for all assigned persons 
(or a "vacant" indication if the position is unfilled). On an as-needed basis, the 
NCOIC prints the personnel position list for each section. Each section NCOIC, if 
necessary, updates his list and returns it to the Department NCOIC who then updates 
the master roster. The updated master roster is forwarded to the Department Chief and 


is also sent to the MEPRS section to update their Position Control Roster. 
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Figure 13. Personnel System Data Flow Diagram 
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Figure 14. Leave and TDY Absence Data Flow Diagram 

The Continuing Medical Education (CME) program provides the doctors 
within the hospital the necessary funds for continuing their medical education. Each 
doctor determines his or her educational needs and prepares a CME request which 
includes the estimated cost of travel. These requests are reconciled with the 
department’s allocated CME funds and if sufficient funds are available, the request is 
approved by the Department Chief and forwarded to the Deputy Commander for 
Clinical Support (DCCS) for approval. The DCCS publishes a master list of doctors 


approved for CME travel. The NCOIC requires each doctor who has completed his 
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or her CME travel to provide a copy of the travel claim voucher. Through this 
information, the NCOIC can capture actual CME costs well before they are reported 
by the travel personnel at finance (which can be one to three months after the travel). 
The CME funds are managed closely because actual costs often exceed the estimates 
originally stated in the request. The CME funds are maintained separately from supply 
funds. 

The Department Chief expressed a desire to monitor leave and temporary 
duty (TDY) status. Leave and TDY information is collected in two separate methods 
depending on the person involved (see Figure 14). Doctors send leave and TDY 
requests to the Department Chief, via their chain of command. Requests approved by 
the Chief are recorded in a journal kept by the department administration section and 
forwarded to the DCCS. The doctor must also notify the Assistant Department Chief 
(ADC) of any planned absences for scheduling purposes (see Figure 9, Scheduling). 
The hospital Personnel Administration Center (PAC) types approved requests on a 
Department of the Army (DA) Form 31. This form is routed through the hospital 
distribution system to the NCOIC who distributes it to the doctor's respective section. 
Other personnel leave and TDY requests are routed through the Medical Company 
chain of command. After approval by the Medical Company First Sergeant and 
Commander, these requests are forwarded to the PAC, typed on a DA Form 31, and 
distributed via the department NCOIC to the appropriate section. 

The Department Chief’s main concern in managing personnel is planning for 
position vacancies and temporary absences due to leave and TDY. Presently, section 


chiefs report upcoming losses on an exception basis only, primarily when the position 
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involved is critical to section operations. The PAC has the capability to report military 
personnel losses on a 30, 60, 90, 120, 150, 180, 270, and 300 day basis, but this 
information is available only on a hospital-wide basis. 

4. Scheduling System (see DF'Ds, Figures 15 and 16) 

The Department Chief’s primary concern for scheduling lies in two clinics, 
the Family Practice clinic and the CTMC/FP clinic. Figures 15 and 16 show the 
doctor scheduling process as it currently exists in each of these clinics, respectively. 

a. Family Practice Scheduling 

The Family Practice scheduling system involves two primary schedules, 
the On-Call Schedule and the Clinic Schedule, and a secondary schedule, the Walk-In 
Schedule. The Assistant Department Chief (ADC) creates each of these schedules. 
This process is very subjective and difficult to define precisely. Each of the following 
sections describes the process for each of the schedules discussed above. 

(1) On-Call Schedule. The On-Call Schedule establishes which doctor 
will be on-call for each night of the month. The On-Call Schedule affects every clinic 
within the department except the Emergency Medical Services which have their own 
on-call schedule. To create this schedule, the Assistant Department Chief (ADC) 
maintains several different files which help him determine which doctor to schedule for 
each day. 

Every clinic has a minimum number of doctors which are required 
to be on duty each day. This information is maintained on a sheet of paper in the 
ADC’s scheduling folder and is necessary for creating the On-Call Schedule because 


a doctor who is on-call one day will not be available for duty the following day. The 
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ADC also maintains historical data for each doctor showing the number of times the 
doctor has been on call on holidays and weekends. The ADC keeps 3" x 5" cards 
with special requirements for each doctor such as continuing education, or conference 
dates for which the doctor would be unavailable for on-call duty. The doctors must 
also inform the ADC when they are requesting leave or when they will be away on 
temporary duty (TDY). The last information kept by the ADC is a cumulative 
monthly tally of the number of times each doctor has stood on-call duty for the last 
calendar year. After considering all of this information, the ADC creates the On-Call 
Schedule in a manner which will be fair to all of the doctors and yet fill the 
requirements for on-call duty and the following day’s clinic schedule. The on-call 
schedule is distributed to each doctor, the patient care nursing stations on each ward, 
the emergency room, and the Clinical Support Division. In addition, the on-call 
schedule is used to create the clinic schedule for the Family Practice doctors. 

(2) Clinic and Walk-In Schedules. As with the on-call schedule, the 
clinic schedule is created by the ADC after considering all of the information relating 
to doctor availability. Staff doctors have a permanent clinic schedule for each month. 
This is affected only by leave requests and TDY orders from the doctors themselves. 
The ADC must also schedule residents-in-training for clinic duty. Each resident is 
assigned a primary location for each month by the Resident Director. The ADC keeps 
this information in his scheduling folder along with special instructions for each 
resident from his assigned clinic. These instructions, on 3" x 5" cards, contain 
information on the daily availability of the resident for duty in the Family Practice 


clinic. Also affecting the clinic schedule is the previous day’s on-call schedule: the 
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doctor who was on call the previous day will not be available for work in the clinic 
on the day in question. The ADC creates the clinic schedule based on the number of 
doctors available for each day of the month. The final clinic schedule is submitted to 
the COSTARS data entry clerk so the appointment system can be updated to show 
which doctors will be available to see patients in the scheduled month. Also, for each 
day on the clinic schedule, the ADC schedules one doctor to see walk-in patients. 
This doctor is then responsible, on the day assigned, to see all family practice patients 
who could not get an appointment but required immediate care. The walk-in schedule 


is attached to the final clinic schedule and distributed to each doctor. 


a A IN & CLINIC SCED> 






E kii 
MINIMUM <4 OF DAS REQUIRED IN CLINIC DAILY) 
PERSONNEL STAFF DOCTORS 
REQUIREMENTS PERMANENT DAILY 
SHEET i SCHEDULE SHEET 
LEAVE/TDY REQUESTS> 
«DR ON CAL HISTORY) (LEAVE/TDY REQUESTS> (CLINIC SCED> 
DUTY (CALL SCHEDULE) 
HISTORY SHEET <DRS DAILY SCED> 





«CALL SCHEDULE > m 
d Erud 


E (FINAL CALL SCED> PDISTRIBUTE 
ON CALL 
BA ee DR REQUIREMENTS> E 


H 
O OSEA —  — 
REQUIREMENTS RESIDENT S 
315 CARDS «CLINIC SCED) SPECIAL 
' INSTRUCTION 
315 CARDS 


ZE AVAIL 


(RESIDENT'S CLINIC LOCATION) 


Mal ative "ET E 
TALLY SHEET <MONTHLY OK CALL HISTORY> EA E 
Pz “RESIDENT'S 5 


MONTHLY 
+ ON CALL SCHEDULE LOCATION SHEET 


Figure 15. Family Practice Scheduling Data Flow Diagram 
b. CTMCIFP Clinic Schedule 
The Chief of the CTMC/FP clinic completes his clinic schedule in 


much the same manner as described for the family practice clinic. The on-call 
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schedule created by the ADC includes CTMC/FP doctors and therefore impacts the 
CTMC/FP daily clinic schedule. The Chief of CTMC/FP uses the previous day’s on- 
call schedule to determine which doctor will not be available for duty on the current 
day. Additionally, he receives each of the CTMC/FP doctors leave and TDY requests 
and special availability requirements which he maintains in one log book. He consults 
this log book and the on-call schedule for the upcoming month to create the CTMC/FP 
schedule for that month. He distributes this schedule to each doctor and one copy 1s 
sent to the AQCESS data entry clerk who updates the appointment scheduling database 
to reflect the doctors available for appointments in the CTMC/FP clinic for the 
upcoming month. 

As can be seen from the previous discussion, the scheduling process 
is subjective and dependent on the historical files and log books maintained by the 
clinic schedulers. The most difficult part of this process is obtaining and coordinating 
all of the information sources which affects the doctors’ availability for duty on any 
given day of the month. The ADC estimated that it required 3 to 4 hours to create 


the monthly schedules because of the many factors influencing the entire process. 
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Figure 16. CTMC/FP Scheduling Data Flow Diagram 
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5. Patient Satisfaction (see DFD, Figure 17) 

Determining patient satisfaction is a subjective process and is currently 
performed by the department's quality assurance representative. The QA representative 
created a questionnaire to obtain subjective responses from patients on various topics. 
The patients are asked to respond "Yes", "No", or "Not Applicable" to eleven questions 
conceming the care they received in the Family Practice clinic. This is the only clinic 


currently using the patient satisfaction survey. 
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Figure 17, Patient Satisfaction Data Flow Diagram 





On one day of each month, the doctors in the FP clinic are asked to 
distribute the questionnaires to the patients they see, with instructions that the patient 


retum the surveys to the receptionist at the nurses station. The receptionist gives all 
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of the collected surveys to the QA representative who then calculates the percentage 
responses for each of the questions and produces Monitor and Evaluation Reports. 

Each Monitor and Evaluation (M&E) report prepared by the department 
QA representative represents an important aspect of care recognized by the hospital QA 
Division (see example, Figure 18). Each question in the survey is an indicator of one 
of these important aspects of care. Each question (indicator) has an assigned threshold 
(listed on the M&E report) which the clinic desires to remain above. When the results 
of the survey are tallied, the QA representative pencils in the patient response rate for 
each question next to the corresponding threshold on the M&E report. The completed 
Monitor and Evaluation report’s are used as an indicator of how successful the 
department was in reaching the thresholds for each of the important aspects of care. 

These Monitor and Evaluation reports are maintained in a binder kept 
by the QA representative and are used at the monthly QA meetings to report on the 
general level of patient satisfaction for each of the important aspects of care. No other 
reports are created using the information obtained from the questionnaires and trends 
in patient responses are not maintained. The Department Chief does not receive a 
copy of the Monitor and Evaluation reports unless he requests them. 

6. Productivity (see DFD, Figure 19) 

The DFD in Figure 19 depicts the current information processes 
involved in reporting productivity for the DFPCM. The CTMC/FP section is the only 
section reporting productivity to the Department Chief. The primary reason for this is 


the fact that the CTMC is an ancillary service specially monitored by the Clinical 
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MONITOR & EVALUATION 


SCOPE: Patient satisfaction 


IMPORTANT ASPECT OF CARE: patients will be treated courteously and 
professionally by the staff. 





THRESHOLD 
INDICATORS: 
1) Survey indicates records ready ai tbe front desk "o 90% 
2) Survey indicates screening prompt and private 2^. 90% 
3) Survey indicates waiting time will be 30 min or less 90% 


SOURCE OF DATA: patients’ survey 


* 


METHOD OF COLLECTION: Family practice receptions clerk provides 
patients with survey to be completed after appoinmen!. 


WHO TO COLLECT DATA: Receptions clerk to forward to nurse or QA 
co-ordinator 


SAMPLE SIZE: 30 


TIME FRAME: One day per month, every other month starting with 
August88 


Figure 18. Monitor and Evaluation Report 
Support Division. The CTMC/FP appointments and patient visits are tracked by the 
AQCESS system. 

The AQCESS system produces a report called the Validated 
Appointment Roster which shows the actual patients seen the previous day. This report 
is sent to the Clinical Support Division which counts the number of patients actually 
seen by the CTMC, per provider. A cumulative total is kept for the entire month. At 
the end of the month, the Clinical Support Division enters this information into a 


LOTUS 1-2-3 spreadsheet. The resulting productivity reports are sent to the Chief, 
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DFPCM. These reports provide information on daily, weekly, monthly, quarterly, and 
yearly workload in tabular and graphical formats. Provider productivity is also reported 
in a tabular report showing the number of patients seen each day, by provider, for the 
reported month. 

Although the productivity of all of the sections is not directly reported 
to the Chief, the data necessary for producing clinical productivity information is 
gathered by each section. The remaining sections use either AQCESS, COSTARS or 
manual logs for gathering workload data. Patient visit information is then reported to 
the Patient Administration Division (PAD). PAD collects and forwards all hospital 
workload information to the Health Services Command on the MED 302 report both 
electronically and in paper format. This report is used in the formulation of future 
budgetary allocations to the hospital. Figure 20 illustrates how the various department 
clinics currently input their workload information to PAD. All of the workload data 
collected by the department's various sections is also stratified according to patient 


demographics, e.g., active duty, dependents, retired, service, etc. 
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Figure 19. Productivity System Data Flow Diagram 
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The Department Chief wants productivity information for all of his 
clinics, similar to that provided to him by the Clinical Support Division for the 
CTMC/FP clinic. The raw data for creating most of this information exists in the 
current systems but is not being used because of time and personnel constraints, and 
other factors which were not readily identifiable. 


E pe | 
FT ES E pe | ES 
ES ES 


ae (Proc edur es? 


EU D (Procedur es) "Mesi 
WI ` Lesser + RADIOLOGY 
PRACTICE (Medical Sua Rp DEPARTMENT <MED-302> 
CIR 
" / «Fr oc edur es? 
APPROVE 





© 





MED-302 











GENERAL EMERGENCY T CREATE ca 
DUTF ATIENT TREATMENT AS AE ORD ==) || ED-307 (Wor ksheet > REPORT 
CLINIC FACILITY (Wor kl oad > WORKSHEET 
(310? / (3105) 
FAMILY | (Approved MED- 302) MED-302 SUM REPORT 
PRACTICE d Ee 
CLINIC MEDDAC FORM 
310-1 FILE 
(310) (310) (310) ^ mex) — 302 
PRESIDID 4310» HEALTH SUMAR Y 
DOCTOR SEN REPORT 
FLIGHT inui 
SURGE ON 
OF FICE 
BATTALION 
AID 
A A a 
(procedures) 1-RAY SECT 


A (procedures) 


Kä ` EA 
EA 
NOTES: 


, Input visits by appointeent ad 
(3107 Meddac Fora 310-1 (climic visits worksheet) 


Figure 20. Clinic Workload Data Flow Diagram 
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IV. FUNCTIONAL SPECIFICATIONS 


A. INTRODUCTION 

Chapter III presented the DFPCM’s current information systems relating to six 
specific areas: budget, equipment procurement, personnel, scheduling, patient 
satisfaction, and productivity. This chapter summarizes the current system's 
deficiencies and examines the failure of automation to meet the department’s 
information requirements. 

Additionally, this chapter proposes general improvements for each of the six 
areas and discusses the impact of these solutions, and the impact of automation on the 
department’s information systems. The detailed system improvements for each of the 


information systems are presented fully in Chapter V, Requirements Analysis. 


B. CURRENT INFORMATION SYSTEM DEFICIENCIES 

The Chief of the DFPCM makes many decisions which affect both his personnel 
and resources, and greatly impacts the entire hospital. The nature of his responsibilities 
and the span of control he is required to exercise place additional emphasis on the 
significance of these decisions. Facing both time constraints and limited resources, he 
needs the right information, at the right time, and in the best format to accomplish his 
objectives and meet the needs of the department and the hospital. In analyzing the 
existing department information system, we discovered many deficiencies which hinder 


the Department Chief's ability to make informed decisions. 
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In general, the reports and other information the Department Chief receives are 
complex and difficult to quickly comprehend because they are not summary in nature. 
In interviews with the Department Chief, he expressed a desire for information which 
would depict long term trends and show department performance over a predetermined 
period of time. Much of the information he gets now is a "snap-shot" in time which 
does not allow him to see the "bigger picture" without pouring through many similar 
reports. In a few cases, the data is simply too time consuming to analyze (e.g., 
budget, equipment and personnel information) and, therefore, never becomes meaningful 
information for the Department Chief. 

In addition to poor information, the Department Chief occasionally has difficulty 
getting enough information. One of the Department Chief's concems is having sound 
information to help justify his decisions to higher authorities and support his actions 
in managing resources and personnel. Missing information due to informal reporting 
standards or poor data collection impedes his decision abilities in these areas. 

Another concern of the Department Chief is the importance of feedback. The 
Department Chief feels it is critical for each section to receive sufficient, and timely, 
feedback on their performance to allow them to become more effective and efficient 
on there own initiative. The sections currently receive very little in the way of 
constructive feedback and the information they do get is prone to the same problems 
discussed above. 

Unfortunately, inconsistent reporting requirements and system capabilities exist 
throughout the department so that each section is substantially different from the others 


in the information it is able to report. This contributes to many of the problems 
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described in the preceding paragraphs. Succinctly, the current information system is 
not meeting the requirements of the Department Chief. We feel the majority of these 
obstacles can be attributed to limited personnel resources, time constraints, and 


ultimately, the incompatibility of the hospital’s automated information systems. 


C. THE FAILURE OF AUTOMATION TO MEET INFORMATION 
REQUIREMENTS 


Chapter II introduced the three major automated information systems in place in 
the hospital: MEPRS, AQCESS, and COSTARS. These systems hold huge stores of 
data which can potentially produce meaningful information. In addition to these 
medical information systems, the hospital uses other Army-wide systems for accounting 
and logistical data. Microcomputers are scattered throughout the hospital providing 
individual computing capabilities in some functional areas. With all of these resources 
at hand and with the rapid advance in information systems technology, the question 
arises, "Why hasn't automation solved the information problems within the DFPCM?" 

There are many reasons why the automated systems at Silas B. Hays have failed 
to meet the information needs of it's key decision makers. The primary factors which 
have contributed to this failure are listed below: 

* The AQCESS, MEPRS, and COSTARS systems are independent and 
incompatible with each other. Data sharing is impractical and duplication of 
data collection and data reporting are wasteful of time and resources. 

* All of the sections within the department do not use the same system. For 
instance, the Family Practice Clinic uses COSTARS for appointments and 
patient records while the Consolidated Troop Medical Clinic, the Family 
Practice Clinic at the Consolidated Troop Medical Center, and the General 
Outpatient Clinic use AQCESS for appointments and patient information. The 


Fort Hunter Liggett and Presidio of Monterey Clinics, the Emergency Medical 
Services, and the Flight Surgeon's Office are completely manual. 
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e Much of the data kept by the accounting and logistical information systems 
is not divided by departments or sections, making information extraction 
difficult and time consuming. 


* The method of inputs to the various systems are different, making it 
impossible to create standards for data collection and reporting. 


* Hospital personnel are not adequately educated on the capabilities of the 
current information systems. In discussions with various department and 
hospital personnel, it was apparent they were unaware of the information 
available to them or of the procedures required to obtain the information. 

* The reports produced by these svstems are in tabular format and reflect the 
data for one period of time. Trend analysis over time is impossible without 
further manual manipulation of the data. Summary information is also difficult 
to obtain. 

Although most of these problems are unsolvable within the scope of this thesis, 


evaluating the difficulties they create within the department's information system will 


assist us in identifying specific requirements for an improved information system. 


D. PROPOSED INFORMATION SYSTEMS 
The first two sections of this chapter addressed the overall problems which exist 

in the current information system. In identifying what the system lacks, we have thus 
helped identify what an improved system will require: 

* Consistent data collection methods. 

e Consolidated information. 

* Concise, summary reports which are easy to read. 

e Analysis of department and section performance trends over time. 

e Easy data input methods. 


e Feedback for department and section leaders. 


e Standard reports. 
* Complete and up to date information. 
The remainder of this chapter is an analysis of the requirements for each of the 
specific areas described in Chapter III. Each section below summarizes the solutions 
we propose, supported by the Department Chief's requests, for the six major areas 
under consideration. 
l. Budget Information System 
a. System Deficiencies 
The Department Chief has a budgetary system that meets only his 
minimal needs. The information listed below is provided to the Department Chief in 
tabular format by the microcomputer based spreadsheet program. 
* Account Processing Code (APC). This code is generated by the Resource 
Management Division to identify separate identified fund accounts. A single 
section can have several fund accounts. 


e Section name. The name the department assigns to each APC listed above. 


e Allocated funds for the Quarter. The funds allocated for each APC for the 
quarter. 


e Supply Expenditures for the Month. 

* Total Department Expenditures for the Month. 

* Total Spent this Quarter (cumulative) 

e Uncommitted Funds this Quarter. 

e Funds per Month (target expenditure for the section). 
e Percent Spent for Month. 


e Percent Saved for Month. This percentage is calculated by subtracting the 
percent spent for the month from 100 percent. 
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* Percent Spent for Quarter. 


e Percent Saved for Quarter. This percentage is calculated by subtracting the 
percent spent for the quarter from 100 percent. 


This information, though adequate, does not provide him with an easily decipherable 
format nor the capability to track spending habits for more than one month. The data 
used to generate the report, the Month End Report, is accurate but does not necessarily 
reflect any recent section expenditures. In spite of this problem, the information from 
the Month End Report is still considered accurate enough to be a good indicator of 
expenditures for the Department Chief. 

The Department Chief also receives budget information from the two 
intradepartmental reports, the Resource Information Report (RIR) and the Budget and 
Equipment Analysis Report (BEAR). The budget sections of these reports are meant 
to provide the Department Chief with up to date budget information that is not 
currently reflected on the monthly budget worksheet. Though these reports were 
designed to report more current budget information, the information actually reported 
on the RIR and BEAR reports is a duplicate of the budget information already 
provided on the budget worksheet. In fact, the Department NCOIC stated that he often 
recopies the budget data onto the reports from the Month End Report. 

The Department NCOIC currently maintains old copies of each budget 
report on computer disks. As each new report is needed, the Department NCOIC 
gathers the current information necessary to complete the spreadsheet. He gathers this 
data from either the current Month End Report or in the case of a quarterly or yearly 


recap report, from previous monthly reports. Once this new spreadsheet is created for 
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the report, he enters the sections’ expenditures for the period into the spreadsheet. The 
input of each section’s expenditure requires the Department NCOIC to search through 
the spreadsheet and find the location where the information must be entered. Although 
this process is not necessarily difficult, it is cumbersome and requires the Department 
NCOIC to have a working knowledge of both the spreadsheet’s format and the 
application program. This system can be handled by a highly computer literate 
individual like the current Department NCOIC, but could easily become unworkable 
under a different NCOIC. 

Data analysis requiring more than one month’s data would involve the 
combination of several separately maintained spreadsheets. The old data is replaced 
each time a new report is created. The elimination of historical data makes long term 
trend analysis extremely difficult and cumbersome. 

b. Proposed System Improvements 

Data entry can be made simpler by standardizing the screen displays 
and inputs and by making the program environment transparent to the user. This data 
can also be maintained in a more accessible format, such as a database, for ad hoc 
inquiries. Maintaining the data within one consolidated database will also provide the 
capability to do long term analysis of expenditures. This ability to access the data 
allows the sections to retrieve information on their performance in the same format as 
seen by the Department Chief. 

The data output can be improved through the use of graphs. The 
graphs will be used to display budgetary trends on a yearly basis which provides the 


Department Chief with a clearer picture of the budget fluctuations and trends over 
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time. These graphical printouts allow better analysis of the budget information with a 
lot less mental manipulation of the data. Printed tabular reports can be improved by 
reorganizing the presentation of the information. 
c. Impact of Automation 
Dr. Ertel best characterized the role of the microcomputer in automation 
by his statement: 
The proper role for the computer is to do what it does best: scan large numbers 
of records...rapidly, apply its infallible memory for detail, and serve as a 
communications link. (Ertel, 1984, p. 485) 
The primary goal in our requirements specification is to avoid the creation of any 
additional and senseless work. This means avoiding the automation of something that 
does not need automating while automating those things that best fit the advantages of 
the microcomputer. 
The budget system is already automated, though only in a limited sense. 
The improvements described in the previous section will have the following impact on 
the current information system: 


e Simplification of the input process. 


e The capability to maintain a larger database to facilitate trend analysis and 
graphing. 


e Enhance the information’s worth to the decision maker. 


* The capability to graph the data versus displaying it in its current tabular 
format. 


e Reduce the amount of time the person who receives the information must 
spend in deciphering the data to turn it into useful information. 


* Provide for a user friendly system that will not require the user to master a 
computer or to learn a particular applications program. 
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e Providing the user with a menu driven work environment should make the 
transition between users less complicated. 


e Enhance the choice of outputs (the ways the data can be viewed) for the 
Department Chief and his sections. 


d. Impact of Proposed System 
The information provided by the new budget information system will 
provide the decision maker with a more succinct view of the budget information than 
he currently receives. As discussed in the introductory sections, the Department Chief’s 
time is limited and the ability to see the impact of information quickly without any 
major data manipulations is critical. The addition of a trend analysis capability will 
provide the Department Chief with the ability to forecast and manage his future budget 
requirements. By being able to pictorially depict his budget trends and status, the 
Chief can keep himself, his subordinates, and his superiors better informed. 
2. Equipment Procurement Svstem 
a. System Deficiencies 
The current equipment needs are identified through three sources: the 
Resource Information Report (RIR), the Budget and Equipment Analysis Report 
(BEAR), and the Information Capability Request (CAPR). The equipment needs 
identified by each of the department's sections are provided by the equipment sections 
of the RIR and BEAR reports. The Department Chief identifies new automated 
equipment requirements through the Information Capability Requests (CAPR). 
The RIR contains the following equipment information: 
* Old Equipment Status. 


* New Equipment Status. 
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e Medical Care Support Equipment (MEDCASE) items (equipment needed). 
* Capital Expense Equipment Program (CEEP) items (equipment needed). 
The BEAR contains the following equipment information: 


* Equipment to be replaced (immediately, within one year, within two years, and 
within three years). 


e Money needed for equipment replacement (immediately, within one year, 
within two years, and within three years). 


* Actual approved items now on the CEEP and MEDCASE program with the 
date item ordered and its projected arrival date. 


* Paper work in progress for placing equipment either on the CEEP or 
MEDCASE programs and its paperwork status. 


The problem with the information provided in the RIR and BEAR reports is 
redundancy. Each report seeks to collect information on only the high priority 
MEDCASE and CEEP requirements but within two different timeframes, quarterly for 
the BEAR and monthly for the RIR. These reports provide the Department Chief with 
only a limited look at his equipment needs and tend to track only those needs that are 
the most urgent (usually only MEDCASE and CEEP items). The reports do not give 
the Department Chief a consolidated look at all of his department's requirements. This 
fragmented approach to capturing the data makes it an intricate process for the 
Department Chief to estimate his future equipment needs. Since funds are limited, the 
Department Chief stated that he needs a consolidated listing of all his requirements to 
set replacement priorities throughout the department. The consolidation of this 
information would also be beneficial when bargaining with the hospital’s equipment 


acquisition board (Programmed Budget Advisory Committee). 


69 


The CAPR requests provide the Department Chief with the following 
information: 


e Functional area supported. i.e., automation, communications, records 
management, printing/publishing, and visual information. 


e Justification for the equipment. 


e A description of the changes and the reasons for the change to the existing 
service (if applicable). 


e Source of funding for the equipment. 
These requests are only tracked as they are generated. 

The process of consolidating the equipment requirements identified in 
the BEAR, RIR, and CAPR requests is tedious and requires the Department Chief to 
manually consolidate all the section’s separate reports. The current system also does 
not allow him to track the long term equipment requirements needed to determine if 
there are department-wide problems in the acquisition of equipment. 

Other equipment needs that may not be as critical are not tracked or 
monitored. In addition, the Department Chief cannot track the section’s past reported 
requirements which are either inadvertently or deliberately not listed on the current 
report. This requires him to either remember all of the past requests or manually 
search through the old RIR and BEAR reports to obtain this information. 

The status of high priority equipment requests are reported on the 
BEAR and RIR reports. The only way to see the status for this equipment is to review 
each section’s RIR and BEAR reports for this information. The Department Chief 


simply does not have the time to do this. 
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b. Proposed System Improvements 


Any solution proposed for the equipment information system will 


undoubtably create some additional work for the department. Therefore, the primary 


consideration for the new equipment information system will be ease of data entry and 


familiarity with the entry format. The greatest improvement to the current system can 


be accomplished by the creation of a consolidated database where all equipment 


requests can be recorded and easily tracked. To identify equipment requirements, the 


Department NCOIC suggested the following types of information be used in the 


database: 


Item description. 

National Stock Number. 

Section requesting the equipment. 

Date requested. 

Type of request (MEDCASE, CEEP, CAPR, Other). 
Priority of equipment within a category. 

Urgency of need (immediate, one year, etc.). 
Quantity desired. 

Unit price and associated extended price. 

Status Of request (requisition number). 


Cumulative recap of required expenditures. 


Once an item is deleted from the active database due to the delivery of the equipment, 


its data should be relegated to a historical database for the analysis of long term 


equipment trends. 
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The design of the user interface is critical. Once again, data entry 
should be simple and straightforward. The outputs can reflect either a recap by 
equipment category or a consolidated listing of all equipment requirements. The current 
reports should be consolidated into a single report and standardized and simplified to 
match the inputs required by the user data entry interface. The system should be built 
to facilitate ad hoc inquiries on the database and to do limited mathematical 
calculations to subtotal categories and run cumulative totals within categories. 

c. Impact of Automation 

The equipment procurement information system is not currently 
automated. The most far reaching impact of automating this system will be the work 
required to enter data from the consolidated Resource Information Report into the new 
equipment database. On the other hand, the Department Chief considers the 
availability of this information important for resource management. As stated earlier, 
a well designed user interface should limit data entry to the format recognized in the 
RIR. Specifically, automation will: 

* Provide the department with a consolidated listing of all equipment 
requirements and the capability to report separate categories without leaving 
the database. 


* Provide the Department Chief with the ability to request the information in the 
format he needs for a particular situation. 


* Provide a historical database of equipment requirements that can be analyzed 
to determine equipment procurement trends over the long term. 


The Department Chief currently feels that the benefits associated with automation in 


this area will far exceed the costs, provided the user interface is kept simple. 
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d. Impact of Proposed System 

The proposed system will provide the Department Chief with a 
consolidated listing of all his sections” equipment requirements. This information will 
provide him with a capability to sort equipment needs by cost, category, or priority 
within the separate equipment categories, e.g., CEEP, MEDCASE, etc. In this 
information lies the ability to bargain with the hospital resourcing committees by 
having the information readily at hand and in a format which will facilitate this "give 
and take" environment. By knowing all of his requirements, the Chief can better 
manage his resources to meet those equipment needs that are the most critical to his 
department's success. With his limited time, the consolidated format allows him to 
digest the information quickly. Through the listings of future needs, he can better plan 
the budgets to meet those needs. This new system will serve to facilitate unique 
information needs quickly and with less inconvenience in obtaining that data. 

3. Personnel System 
a. System Deficiencies 

As discussed in the previous chapter, the Department Chief has two 
areas of concern with the personnel information system: tracking and reporting 
manpower levels and funding for the Continuing Medical Education (CME) program. 

The Department Chief currently tracks personnel manning levels by 
maintaining this information within a word processing shell. This format is not easy 
to update. It limits the types of reports you can generate and the type of analysis that 
can be done on the data. Without an ad hoc capability, the Department Chief must 


visualize position vacancies by scanning the complete listing. This format also restricts 
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the types of additional data that can be maintained with the personnel listing, i.e., 
doctor patient panels, productivity information, or leave and absence requests. This 
also precludes any data interfaces with other information systems, such as scheduling. 
The update process is complicated in that it involves printing the entire form and then 
cutting the report into individual sections. Likewise a section which requests a listing 
must be satisfied with a department-wide listing. 

The CME listing is currently maintained on a spreadsheet. This type 
of format, though adequate, hampers the ability of anyone to do ad hoc analysis. Any 
trend analysis beyond the current year is limited. A person unfamiliar with the 
application program may have difficulty updating the CME spreadsheet. 

b. Proposed System Improvements 

The current personnel listing can be integrated into a database to 
provide the Department Chief with the capability to keep critical personnel information. 
The database should contain the following database files: 

e Position Information (TDA position, authorization, etc.). 
* Personnel Information (Name, SSN, and Known Loss Date). 


* Personal Information (Protected, including address, spouses name, children, 
birthday, telephone number, etc.). 


e Leave/Absence Log (Interfaces with CME listing and scheduling system, but 
would also include other types of absences, i.e., leaves, emergency leaves, 
other TDY, or unusual planned absences). 


e CME listing. (Interface with the Doctor listing and the Absence Log but also 


includes critical CME information, i.e., estimated costs, actual costs, 
qualification, etc.). 
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The various relationships between the database files can be kept transparent to the user. 
All requested reports can be created by linking the needed database files. The 
Department Chief will have access to a list of planned absences, anticipated losses, and 
vacancies that he did not have previously. The consolidation of the CME listing with 
the personnel listing will consolidate the data entry requirements under one person, 
therefore freeing critical personnel to do their primary jobs. This type of data format 
facilitates any type of report the sections or the Department Chief could request. In 
addition, the scheduler can receive a list of the planned absences and not have to rely 
on verbal notifications from the doctors (see Section D.4., Scheduling). 

Once again, by building a user interface that is independent of the 
program used, the requirement for any application programming familiarity is no longer 
necessary. 

The current system requires two separate routes for leave requests, 
depending on the person requesting leave. The flow of information can be improved 
by centralizing all the data entry and flows for leaves into one location. By 
centralizing this data flow, the leave requests, as well as personnel updates, can be 
combined to avoid the redundancy of the data maintained. 

c. Impact of Automation 
Automation will improve the system in the following areas: 


* Improved user interface. The system can he independent of the knowledge of 
the user. 


* The choice and diversity of reporting capabilities will be enhanced. 


* The leave log is currently maintained manually. By automating this log, the 
data can be linked to the other systems, particularly the scheduling system. 
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* The data will be made easier to maintain and to update. 


* The Department Chief will be able to maintain a protected personal database 
on his personnel. 


e The need to consolidate all data flows through one central location will involve 
changing some internal procedures within the department. These changes must 
be validated to meet regulations and will cause some personnel changes. 

e The initial setup will be costly in terms of the database. The maintenance of 
this large database will require the use of a data entry clerk, but the work can 
be minimized by a well designed user interface. 

d. Impact of Proposed System 

With an enhanced database, the Department Chief can maintain the type 
of data he needs to track his personnel. Through a vacancy listing and the anticipated 
loss listing, the Department Chief can always know, with one simple listing, the 
vacancies or projected losses that exist in his department. This information can then be 
used at critical hospital meetings to quickly identify his needs in a straightforward 
format. At the same time, the addition of personal information, readily accessible to 
him, makes his job as senior counselor easier. The absence listing gives him a monthly 
listing of the personnel that will not be available during a specified time period. This 
information is critical for monitoring the workload throughout the department and 
greatly enhances the Department Chief's ability to predict periods of high stress due 
to personnel shortages. The management of CME funds will always remain critical. 
Doctors need the necessary education to keep them up to date in their medical practice 


but in periods of increasing resource constraints, the ability to predict and justify these 


requirements is critical. 
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4. Scheduling System 
a. System Deficiencies 

Scheduling is a complex, subjective process requiring a great deal of 
independent information. In the existing scheduling system, this information is 
collected in many different ways, at different times, and in different formats. This 
information is subjectively interpreted and evaluated to produce the three required 
Family Practice schedules and the CTMC/FP schedules. Specific problem areas within 
the current scheduling process (as shown in Chapter III, Figures 15 and 16) are listed 
below: 

* Doctor's leave and TDY requests are verbal. The scheduler depends on the 
individual doctor to inform him of upcoming absences. There is no standard 
form or time requirements for providing this information. 

* The independent sources of information are maintained informally, i.e., some 
are recorded on yellow legal paper, other information is kept on 3" x 5" cards, 
and still others are typed on regular white paper. 

* There is no formal instruction for the collection or maintenance of the 
information necessary for scheduling. The Assistant Department Chief (ADC) 
currently keeps all the scheduling paperwork in a manila folder and the 
CTMC/PP chief has a green log book in which he records doctor availability 
information. 

b. Proposed System Improvements 
The subjective nature of the scheduling process and the diverse sources 
of the necessary information place restrictions on the improvements which can be made 
and the resulting benefits of these improvements. We feel attempting to automate the 
process, in this case, is infeasible. Automated scheduling applications requires integer 


programming and optimization techniques far beyond the scope of this thesis. 


Additionally, complex scheduling algorithms often require the computing power of a 
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mainframe computer for the rapid calculations and reiterations of scheduling models. 
(Lyons, 1983, p. 438) Therefore, instead of concentrating on the process of actually 
creating the schedule, we propose improved methods of collecting, maintaining, and 
assimilating the necessary information. Developing a scheduling optimization model 
could be the subject of future research. 

As described in the previous section on the Personnel System, an 
automated leave/TDY log could be used to record all requests for leave as soon as 
they are approved by the Department Chief. A simple report listing each doctor’s 
requested leave dates could be produced for the ADC just prior to the creation of the 
following month’s schedule. This would ensure the ADC had all doctor’s leave and 
TDY dates, without having to rely on verbal information or "Post-it-Notes" stuck on 
his office door. 

In evaluating the other methods for collecting and maintaining doctor 
information, we found that automation would again be infeasible. In this case, the 
department schedulers do not have ready access to microcomputers and will probably 
not have access in the near future. Additionally, automating manual records can 
sometimes cause more work than it saves. For instance, in keeping the monthly 
cumulative tally sheet described in Chapter III, the ADC simply puts tick marks beside 
doctors names to show how many times they were on call for the month. If this tally 
sheet were automated, what now takes the ADC 2 or 3 minutes to perform might take 
10 or 15 minutes by the time he turns the computer on, loads the application program, 


and selects and updates the doctor’s information. 
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Improvements can be made, however, if the forms for recording and 
reporting information are standardized and a more formal! method of coordinating the 
information is developed. Using the monthly cumulative tally sheet to illustrate, 
preprinted forms with the months of the year listed across the top and the doctors 
names on the left could be used instead of the handwritten yellow legal paper. Other 
forms depicted in Chapter III, Figures 15 and 16 could be standardized and preprinted. 
This would make formalizing instructions easier and would positively influence the 
scheduler’s assimilation of data when producing the schedules. 

Keeping these standardized forms in a folder or binder is sufficient, as 
long as there are some basic instructions on where to get the printed forms (e.g., the 
department secretary’s office) and the doctor’s leave report so that a newcomer to the 
job will not revert to an unorganized system. 

c. Impact of Automation 

As presented in the last two sections, automating the scheduling process 
for the DFPCM would be infeasible within the scope of this thesis. Where automation 
would benefit the scheduling process is in providing consolidated information 
conceming doctor’s leave and TDY requests. This is discussed more fully in the 
section on personnel. The preprinted forms for standardizing the information collection 
and maintenance functions could be created and kept on a floppy disk in the 
department’s administrative office. They can then be printed as needed by the ADC. 

d. Impact of Proposed System 
The improvements suggested for the scheduling system deal mainly 


with organization and standardization of the information collection, maintenance, and 
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reporting functions. Although the process will remain virtually the same, the 
schedulers will find it much easier to gather and assimilate the data concerning the 
individual doctor’s availability status. Designing a good manual user interface (forms, 
reports, instructions, etc.), like designing a computer user interface (menus, data entry 
forms, reports, screens) is important. "You will learn and use a system better if it has 
a consistent user interface." (Burnett, 1988, p. 29) Organizing and standardizing the 
various forms and reports will assist the scheduler in recording, finding, and 
understanding necessary information. It will also be much easier for him to explain 
the system when he tums the scheduling job over to another person, as often happens 
in the military. Clear instructions are vital for a good transition file. 

The process of scheduling department doctors will, for the time being, 
remain a subjective decision making process. Formalized methods of collecting and 
reporting information, however, will ease the process by allowing the department 
schedulers to more rapidly assess the information presented to them. 

5. Patient Satisfaction System 
a. System Deficiencies 

Patient satisfaction is difficult to define and measure. The concept of 
satisfaction is viewed differently by each patient and is influenced by different factors. 
One person may base satisfaction on the courtesy of the doctor, another on the amount 
of time he had to wait to see the doctor. Some people agree that hospital satisfaction 
is "the consumer's overall emotional feelings about a hospital following his or her 
visit" (Swan, and others, 1987). Because of the differences in opinions on this matter, 


it is important to identify some basic dimensions which might be indicators of 
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satisfaction. The evaluation of these dimensions can then be determined by using a 
questionnaire to measure patient opinion on the various dimensions. It is also 
important to realize that “many questionnaires are developed not with the intent of 
determining global patient satisfaction, but instead, to address only those dimensions 
of satisfaction with which an organization is willing or able to react". (Pelletier, 1985) 

Applying these concepts to the DFPCM involved evaluating the 
effectiveness of the current patient satisfaction questionnaire and the value of the 
information it provides. 

The basic content of the current questionnaire closely matches the 
Department Chief's desires. Table IV shows the dimensions of satisfaction perceived 
by the Department Chief as necessary for effective evaluation of patient satisfaction. 
The current questionnaire covers most of these dimensions except as noted in Table IV. 
The questionnaire lacks two important features: a brief explanation of the purpose of 
the questionnaire; and instructions for completing and submitting the questionnaire. The 
patient currently receives verbal instructions from the doctor distributing the 
questionnaire. These instructions will vary slightly from doctor to doctor. 

The format for obtaining patient response 1s not as effective as it could 
be. Instead of "YES/NO" questions, the Department Chief would like the answers to 
be scaled, e.g., options from poor to excellent using a scale of one to five. "YES/NO" 
questions are considered too restrictive while a scale indicates a degree of intensity 
(Duffe, 1985). For our purposes, a scale would show the general level of patient 


satisfaction with respect to the given dimensions. 
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Table IV DIMENSIONS OF SATISFACTION 


vs ACCESS TO CARE How long it takes to get an appointment. 
WAITING TIME How long it takes to see a doctor. 
COURTESY OF STAFF Doctors, Nurses, Clerks. 


UNDERSTAND TREATMENT Explanation of procedures. 
d CLINICAL ENVIRONMENT Cleanliness of clinic. 


PHYSICIAN TIME Adequacy of time spent with doctor. 
ALLOCATION 


GENERAL SATISFACTION General opinion of the care received for a particular 
visit. 


** Dimensions not included In current questionnaire 


The primary problem with the existing system is in the output generated 
from the questionnaire results. Each question is treated as a discrete entity, one 
indicator of an important aspect of care. As such, only one-time, discrete response 
rates can be obtained for each question. Additionally, the questionnaire results are not 
being tracked or reported. As discussed throughout this thesis, the Department Chief 
wants summary information which depicts comparisons and trends. The Monitor and 
Evaluation reports do not provide this information. 

b. Proposed System Improvements 

There are two basic improvements which need to be made for the 
patient satisfaction system. First, the questionnaire must be redesigned to include all 
of the dimensions of satisfaction identified by the Department Chief, listed in Table IV. 
This redesign must also incorporate the desired scales for applicable questions. In 
addition, the questionnaire should include a statement of purpose and instructions to the 


patient on how to complete and submit the questionnaire. Although some literature 
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suggests that a cover letter be included (Landry, 1987, p. 16), we believe a simple one 
page questionnaire will be received better by the patients and will be easier to collect 
and review. 

Secondly, the results of the questionnaire need to be reported in a more 
meaningful, effective method. The Department Chief should be able to view trend 
lines and other graphical information to determine the level of satisfaction with respect 
to various dimensions. Comparing the dimensions, when appropriate, should also be 
made easier. Providing this information using automation would require the 
questionnaire data to be entered into a computer program which would manipulate and 
compute the desired results and produce the desired output. 

c. Impact of Automation 

If the responses in the questionnaire are coded, the patient response can 
be easily entered into a computer. Once this is done, the application program would 
automatically compute the results and print or display the desired output in tabular or 
graphical form. Automation will allow rapid trend analysis and graph generation and 
provide a means for storing historical results for future analysis if desired. To perform 
these functions manually would require an inordinate amount of time and the resulting 
benefits would thus be outweighed by the costs. The Department Chief has clearly 
stated the shortage of personnel in his department precludes implementing any system 
which would require excessive input or evaluation time. The time the QA representative 
now spends hand calculating the results of the current questionnaire would be converted 
to time spent by a data entry clerk entering the raw data from the returned 


questionnaires. 
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d. Impact of Proposed System 
The proposals outlined above will improve the patient satisfaction 
information system in several ways: 


e A questionnaire which is easy to understand and complete is more likely to 
be submitted by the patients. 


* Improved questions will meet the Department Chief’s stated dimensions of 
satisfaction. 


e Redesigned answer formats (scales) will provide more meaningful information 
to the Department Chief on the level of satisfaction of the patients. 


e Automated applications will free the QA representative from the time 
consuming task of hand calculating the response rates for each question. 


* Through automation, improvements in data analysis, storage, and reporting can 
be realized with minimal time requirements. 


* Producing more meaningful reports will allow the Department Chief to spend 
less time analyzing the data and draw more accurate conclusions from the 
information presented. Trend analysis and historical comparisons will give 
indications of possible problems and potential improvements in the care 
provided by the department. 

6. Productivity System 
a. System Deficiencies 
The main problem with the productivity information system is that only 
the CTMC and CTMC/FP clinics are being monitored for productivity. The 
Department Chief likes most of the tables and graphs produced by the Clinical Support 
Division for the CTMC clinics but would like to receive this information for each of 
his other sections. Unfortunately, all of the sections do not use the same system to 


record patient visits and doctor workload. CTMC uses AQCESS, Family Practice uses 


COSTARS, and other sections use a manual system. Thus, to provide the Chief with 


84 


the information he desires will require collecting and consolidating the clinic and 
doctor workload statistics from each separate clinic. 
b. Proposed System Improvements 

The Department Chief is interested in obtaining productivity information 
for two distinct purposes: monitoring each individual doctor’s workload (based on the 
number of patients seen), and monitoring the overall workload of each clinic (based on 
the total number of visits). 

Monitoring each doctor’s productivity was determined to be beyond the 
scope of this thesis for the following reasons: 


* Only clinics using automated appointment systems, ie., AQCESS and 
COSTARS, maintain individual doctor workload data. 


* Productivity infornation for each doctor would be impractical to obtain 
manually because of the high volume of patients treated by each clinic. 


* The appointment systems use different measures of doctor availability and do 
not factor in doctor absences, e.g., leave and TDY, when computing doctor 
workload. These disparities result in inconsistencies between the resulting 
doctor productivity figures. 

For these reasons, individual doctor productivity will not be discussed in the remainder 
of the thesis but could be the subject of future research. 

Overall clinic workload data, in terms of the number of patient visits, 
is reported monthly by each section to the Patient Administration Division (PAD). This 
information is already mandatory and can be obtained from PAD either manually from 


the printed MED 302 report or automatically from the data in the PAD worksheet (see 


discussion in Chapter III). The use of an automated data capture routine will preclude 
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the sections from having to provide another copy of their workload reports to the 
department. 

The improvements necessary to obtain the clinic productivity 
information involve collecting all of the section’s visit data for entry into an overall 
department system. With a consolidated database of department visit information, 
productivity reports can be produced to show monthly clinic workload and yearly 
productivity trends. The productivity database can be combined with the budget 
database to produce information relating department and clinic monthly expenditures 
to monthly workload data. 

c. Impact of Automation 

Automating clinic workload reporting would result in the following 

benefits: 


* The Chief can monitor the aggregate workload, by section, to determine trends 
in patient visits and the need to shift resources to meet needs. 


* The department will be able to monitor its workload in relation to its budget. 
d. Impact of Proposed System 
The aggregate number of patient visits is important information. The 
number of patients seen by a section can be compared with the dollar amounts of 
supplies used to track and estimate budget requirements and justify spending patterns 
for the Department Chief. The trends and seasonal changes in patient visits can be 


analyzed over time to assist the Department Chief in planning for future requirements. 
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V. REQUIREMENTS ANALYSIS 


A. INTRODUCTION 

This chapter presents the requirements analysis for the DFPCM information 
system. These requirements were determined through prototyping as discussed in 
Chapter II. The requirements analysis is based on the functional specifications for each 
system described in Chapter IV and provides a more detailed look at the inputs, 
outputs, data structures and user interfaces required to meet the functional 
specifications. We used User Concept Diagrams (UCDs), described in the following 
section, to depict the requirements for the systems and aid in establishing the 
prototypes. 

Having analyzed the current system (Chapter III) and proposed improvements 
(Chapter IV), the requirements analysis is the first step toward actually building an 
improved information system. This thesis takes the requirements analysis phase of the 
development life cycle through one iteration of the requirements prototype. The 
number of iterations which will ultimately be required for the prototype is unknown 
and will vary for different development projects. Once the prototypes are accepted by 
the users, the system development can continue with design and implementation. The 
remainder of the chapter presents the identified requirements for the DFPCM 


information system. 
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B. 


USER CONCEPT DIAGRAMS 


Chapter III introduced data flow diagrams as a way to depict the current 


information system. Although DFD’s are being used extensively by systems analysts, 


there are many other methods available for relating information system functions and 


data flows to the user. One of these methods is the User Concept Diagram (UCD) 


developed by Charles F. Martin in 1988. 


Martin designed UCDs to supplant DFDs for representing the information system 


to the user. UCDs have several advantages over DFDs. These advantages result from 


the use of additional symbols to represent entities and interactions not present in DFDs. 


The major advantages are listed below: 


Extemal entity symbols clearly indicate data flows into and out of the 
automated system. 


The use of multiple symbols for external entities more closely depicts the 
objects they are intended to represent. 


The intended user is identified with his type of interface so the interactions 
of the system can be designed for compatibility with intended users. 


Symbols can be easily drawn with standard flow chart templates or automated 
graphics packages. 


Different storage and output mediums can be easily portrayed. (Martin, 1988, 
pp. 65-84) 


Figure 21 shows the basic UCD symbols (more can be created to meet a 


particular analyst’s needs). Although UCDs use more symbols, the resulting diagrams 


are easier to explain to the users hecause they are "pictorially more suggestive of the 


objects they represent” (Martin, 1988, p. 65). We found this to be true in our 
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interactions with the DFPCM users. Thus, in the requirements analyses that follow, 


we use UCDs to depict the department’s information system requirements. 
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Figure 21. User Concept Diagrams 


C. GENERAL REQUIREMENTS 
1. User Interface Design 
The design of the interface is perhaps one of the most critical aspects in the 
development of a prototype for the DFPCM. "Ease of use", "user friendly", and 
“ergonomic design" are all industry buzzwords that simply mean one thing: make the 


interface work for the user in the way they expect it to work in their environment. 
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Many factors determine who will be the users and when and how they will use the 
system. The environment at the hospital provides a challenging set of circumstances 
for the design of the interface. The target DFPCM information system user will most 
likely be a novice, untrained in both computers and applications programs. He or she 
will not have the time to learn complicated applications program because of many 
more urgent duties. The information system will not have dedicated data entry clerks 
and will, in all probability, rely on the availability of someone who has other pressing 
matters at hand. 

Martin’s Human Factors/Computer Knowledge Structure, as depicted in Table 
V, served as the basis for the interface designs in developing the initial prototype 
(Martin, 1987, p. 335). 

To properly humanize software through the use of ergonomic design 
principles, Knittle and Gardner suggest the designer follow the principles listed below 
(Knittle, 1987, pp. 164-171): 

e Minimize worker effort. The user should only perform essential, 
non-automatable tasks, avoiding repetition of work already accomplished 
(Knittle, 1987, p. 164). All inputs should be in the format that the user is 
already familiar with, i.e., a commonly used written form or report. 


e Minimize worker memorization. 


e Minimize worker frustration. Keep the user aware of delays in accomplishment 
and if necessary give them progress reports (Knittle, 1987, p. 166). 


e Maximize use of habit patterns. 
e Notify users of problems promptly. 
e Maximize worker control of tasks. 


e Maximize task support. 
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Table V HUMAN FACTORS/COMPUTER KNOWLEDGE STRUCTURE (Martin and 
Fuerst. 1987, p. 335) 


esl computer eee 
Human factor Human subfactor P 


E 
[ New — | 


Defaults With explanation "Fos Pana 
tion 
Screen discontin- Prompt and keved Keved response 
uation response without prompt 
Full. unsolicited Upon request 
| Help function function 
Full, unsolicited Upon request 


Mean Minimize within Minimize 
` variance i 
Response time Minimi thi 
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Variance inimize i 
| Variance M mean 


Path process 


Overal! scree emer Lo 
ES 2 Minimize Maximize 


Screen design is another aspect of humanizing software. Stahl recommends the 
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following guidelines in the design of screens which support user friendliness. (Stahl, 
1986, p. 60). 
* Do not crowd the screen. "Good screens look good." 


* Use highlighting, blinking, and reverse video sparingly. Overuse will lead to 
operator fatigue. 


9] 


e Use color sparingly. Color is an appealing and proven way to enhance 
computer input. The following foreground/background screen combinations are 
listed in order of legibility, from the most legible to the least legible (lves, 
1982, pp.15-47). 


MOST LEGIBLE Black on Yellow 
Green on White 
Blue on White 
White on Blue 
Yellow on Black 
White on Red 
White on Orange 
White on Black 
Red on Yellow 
Green on Red 
Red on Green 

LEAST LEGIBLE Blue on Red 


e Limit the amount of information on each screen to what is necessary. Do not 
force the user to remember things from one screen to the next. 


e Minimize key strokes. 
e Minimize cursor movement. 


e Show the maximum permissible length of an input field with underscores, 
highlighting, or brackets. 


e Keep the screen consistent with paper input forms. Although all information 
from the paper form may not need to be entered on the screen, the screen 
should follow the general flow of information on the paper form. (Kendall and 
Kendall, 1988, p. 484). 

Messages to the user, an essential element in user friendly screens, should 
be: (1) consistently positioned, (2) short, meaningful, common and fully spelled out, 
(3) affirmative, (4) in the active voice, and (5) in the temporal sequence of events. 
(Galitz, 1983, p. 9). 


Another aspect of interface design is the design of menus. The user should 


be able to identify which transactions are available through a series of logically related 
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and relevant events common to a menu screen. The menu screens for the DFPCM 
information systems are depicted in the following sections by the use of Menu 
Hierarchy Charts. 
2. Standard Interface Designs 
Understanding the importance of a good user interface, we designed a set 
of standard interfaces for getting user input and for displaying output on the screen for 
each of the systems. The following sections describe the standard input and output 
designs which are applicable to all of the systems. Within the detailed requirements 
for each system, we present a specific description of the data required for the inputs 
and outputs related to that system. Appendix A, the Data Dictionary, contains detailed 
information about the data structure of the system's databases. 
a. Input Screens 

The majority of the input screens were generated with a commercially 
avallable database screen generator. The screen generator displays the available fields 
from the database in use and allows the analyst to load and position the desired fields 
onto the screen to create a functional input format. The program which generates this 
screen is saved and called into use whenever the user selects an input option from one 
of the menu systems. Appendix B is the program listing of all of the format screens 
for the DFPCM information system. 

The screen generator allows the system designer to easily load and 
manipulate the necessary input fields to create good user interfaces. The screen 
formats are easy to change to suit the user's requirements, making the generator an 


invaluable tool when prototyping the requirements analysis. Examples of each of the 
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input screens designed are included with the detailed requirements analysis for each 
system, with a description of the necessary input fields. 

Other standard input screens are those used to accept input from the 
user necessary for identifying further processing requirements, such as the year and 
month for a desired report or a person's identification number for updating his or her 
personal information. These screens are created with programming commands which 
identify where the prompts and input blocks appear and any other information needed 
on the screen. An example of these interactive screens is shown in Figure 22. Where 
possible, we have designed these screens to position prompts, input blocks, and 
instructions in the same locations and with similar terminology. Whenever the user is 
asked to input a coded response, e.g., the Section Code shown in the example, he or 
she should be allowed to view a help screen showing the valid codes for that particular 
item, e.g., FPC = Family Practice Clinic. 


| Enter the Year for report: 89 
| Enter the Month for report: 10 | 


E 








Figure 22. Sample Interactive Input Screen 
b. Review Screens 
In many of the system menus. there is an option for reviewing database 
information on the screen. The review screens are easily created with commercially 


available database software (e.g., DBASE M+) by using a programming command and 
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specifying the fields desired for display. An example of a typical review screen used 


in the DFPCM information system is shown below. 


APC DESCRIPTION SECT_CODE POC TELEPHONE 
W357 FAM PRAC CLINIC FPC TURNER 8888888 
W358  CTMC-FPC CFP SHAW 7777777 
W360 EMERGENCY MED EMS BLAKE 6666666 


The field names are printed across the top of the screen, in the order given in the 
program command. The specified fields for each applicable record are displayed 
beneath the corresponding field title. The analyst can program the review screen to 
allow the user to change certain data or prevent the user from making any changes 
while reviewing the database information. Review screens used throughout the system 
are similar in format. The specific fields required for display for each review are 
described within the detailed requirements for the applicable system. As with 
generated screen inputs, analysts can easily update review screens to meet user 
requirements during prototyping. 
3. Requirement Analysis Constraints 

The detailed analyses which follow describe the data structures, menus, 
inputs, outputs, and user interactions for each of the systems under consideration. 
Many of the tables and graphs produced by the systems require extensive data 
manipulations and in some cases, interaction with more than one software package. 
The design of the detailed programming for these data manipulations and extractions 
is beyond the scope of this thesis and is therefore not included in the detailed system 
requirements. The output examples were generated using sample data similar to that 


which would be extracted from the database. Where applicable, the program listings 
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for each system contain comment statements indicating where data manipulations and 
report generation would have to occur to produce the desired output. Within the 
system requirements is a detailed description of the data elements necessary to create 
the outputs. The actual method of output generation will depend on the software 
packages used. For example, if the database software has graphing capability, the 
graphs can be generated internally from the existing data. If not, the data will have 
to be moved to a separate graphics software package to produce the desired graphs. 
These software specific constraints are not included as part of the requirements analysis 
but would have to be considered further in the development life cycle, once the design 


and software selections have taken place. 


D. DETAILED REQUIREMENTS 
1l. Budget Information System (see Program, Appendix C) 

Figure 23, a user concept diagram, gives a picture of the components of the 
new budget information system. The user concept diagram, as discussed in the previous 
section, allowed us to give the Department Chief a general picture of the new 
requirements necessary for the budget information system. 

a. Data Structures 

To successfully meet the needs of the Department Chief, the data 
structure for the budget system was designed to provide maximum flexibility in data 
retrieval and analysis. Each database was designed to represent a portion of the budget 
process, e.g., the receipt of the quarter’s budget allocations or the receipt of the 
section's expenditures as reported in the month end report. Figure 24 represents how 


each database relates with the other databases in the budget information system. 
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Figure 23. Budget Information System User Concept Diagram 
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The structure of the data fields facilitates the combination of databases 
through the use of relationships among the key fields between the databases. The key 
field identified throughout the budget databases is the Account Processing Code (APC) 
which is used within the hospital for financial accounting purposes. 

The APC database contains the following data fields: 

* Account Processing Code. Hospital-wide funding code. 


e Section Description. This is the specific department name associated with a 
particular APC code. 


Section Code. This field was designed to represent the true organizational 
structure of the department. It allows the system to interrelate sections along 
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organizational lines versus the artificial budgetary lines necessitated by the 
APC funding codes. This convention allows other subsystems of the DFPCM 
information system to relate budgetary information along the same command 
lines, such as is necessary in the Productivity system. The codes used in this 
field include: 


DEP Department Headquarters 

FPC Family Practice Clinic, Main Hospital 
CFP Family Practice Clinic, Troop Clinic 
GOC General Outpatient Clinic 

EMS Emergency Medical Services 

POM Presidio of Monterey Health Clinic 
CTM Consolidated Troop Medical Clinic 
FHL Fort Hunter Liggett Clinic 

AMB Ambulance Section 

FSO Flight Surgeon Office 


Point of Contact for budget matters within the section. 
Telephone Number. Self Explanatory. 
Status Code. A system code, either "A" for active, or "I" for inactive. This 
code is needed to allow APCs which are no longer in use (identified by an 
I) to continue to be linked with budget data to maintain long term historical 
APC information. The APC code, once entered into the system, is never 
deleted. Only active APCs (coded A) are displayed when a user requests an 
APC listing. 

The APC Allocation Database contains the following fields: 
APC code. Described above. 
Fiscal Year (FY). 


Quarter. The quarter of the given fiscal year. 


Allocation: The funds allocation for the APC in the first field further 
delineated by the Fiscal Year and Quarter fields. 


The APC Monthly Expenditure Database contains the following fields: 
APC code, as described earlier. 


Fiscal Year of expenditure. 
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* Month of expenditure. 


e Quarter of expenditure, computed from the month field, i.e., if month is 10, 
quarter is 1. 


e Expenditure for the month. 


APC INFORMATION DATABASE 
Account Section Section Point Telephone APC 
Processing Description Code of Number Status 
Code Contact Code 


ALLOCATION DATABASE 


Account Fiscal Quarter Funds 
Processing Year Allocated 
Code BEF ppa o (Allocations) 

Account Fiscal Quarter Funds 
Processing Year Expended 

Code (Expenditures) 


MONTHLY EXPENDITURE DATABASE 


+ + ++ 
* » » * 
+ + ++ 


Figure 24. Budget Information System Data Structures 
b. Data Inputs 
The user will be required to maintain the databases discussed above 
through three database interfaces. The three interfaces are: 
e Enter or delete quarterly allocations. 
e Enter or delete monthly expenditures for each section. 
e Enter or change the status of a section’s APC information. 

The menu hierarchy chart is depicted in Figure 25. As discussed in the 
previous section of this chapter, the user is required to enter the fiscal year to limit the 
database search. If necessary, the month or quarter within the selected fiscal year is 
also entered. These entries are standardized as discussed in Section C, General 


Requirements. All entries within a particular menu cycle are restricted to the user’s 


99 


chosen fiscal year. This restriction is desired because most data entries will require the 
same fiscal year since the user usually works in one fiscal year at a time. To change 
fiscal year while working in the selected menu, the user must return to the main menu 
and enter the new fiscal year when prompted. The entries within the selected menu 
cycle are limited to the chosen fiscal year so the user does not have to re-enter the 
fiscal year for each additional expenditure or similar input. 

In the cases where the APC is entered by the user, the system verifies 
the code entered against the active APC information database and, if the APC is found, 


confirms the user’s choice with the following screen. 


Section: ESS Section Code: Bag 
Point of Contact: es Telephone: 


This confirmation prevents the entry of either a wrong or inappropriate APCs that 
would destroy the integrity of the allocation and expenditure databases. If the APC is 
not found, an appropriate warning is issued to the user and he or she is allowed to 
try again. 

Figure 26 is a picture of the user input screen used for the entry and 
deletion of a quarter’s budget allocation for a given APC. The fiscal year, APC, and 
quarter have already been entered hy the user and will appear on the input screen. 
This screen is modified when used in the deletion process by the addition of a 
comment, Delete this Record? (Y/N) Bi , at the bottom of the screen. 

Figure 27 depicts the user input screen that allows the user to enter the 
monthly expenditures for a particular APC. As discussed previously, the user can only 


enter the actual allocation for the month. The month and APC have already been 
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Figure 26. Quarterly Budget Allocation Input Screen 
Enter the Monthly Expenditure 


APC Code W-156 
Month 10 


Expenses 





Figure 27. Monthly Expenditure Input Screen 

Figure 28 depicts the user input screen that allows the user to enter or 
change an APC. The entry of a new APC is preceded by verification that the APC 
requested is not in the current database. If the requested APC is found in the existing 
database, the user is warmed and allowed to try again. The user is not allowed to 
reenter the APC once the screen in Figure 28 is presented. This prevents redundancy 
in data entry and keeps the user from circumventing the duplicate APC check 
procedure. The section codes are displayed on the screen to facilitate user entries. 


Inactivation of the APC is allowed when the user is prompted with "Do you wish to 
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put this APC into inactive status? (Y/N) Ir the user wants to change a 
particular APC’s status code to inactive, the APC record is automatically annotated 
with the new status code. Activation to an active status is automatic when the user first 


enters a new APC. 
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Figure 28. APC Information Input Screen 
c. Outputs 

Outputs are divided into two general categories. Review screens 
(discussed in Section B of this chapter) and pre-formated reports. The three general 
review screens presented to the user are depicted in the menu hierarchy chart in Figure 
25 as the menu options either to review allocations, expenditures, or all of the APC 
information. Each review option provides the user with the generic review display 
as described in Section B of this chapter. The data fields presented in each case are 
the complete data fields of the respective active database. 

(1) Monthly Budget Expenditure Report. Figure 29 is an illustration 
of the monthly budget expenditure report. This report serves as the Department Chief's 


indicator of the month to month status of the department's budget. This report is 


critical to the monitoring of the section’s compliance with the department’s budget. 
This report is also provided to the section chiefs for the same reason. 

The user is prompted to enter the fiscal year and month desired 
prior to the output of this report. The databases and appropriate fields necessary to 
create the report are listed below. 

e APC, extracted from the Monthly expenditure database. 

e Section Description. This information is obtained from the combination of the 
APC database with the Monthly Expenditure database to obtain the title for 
each APC in the monthly expenditure database. 

e Allocation for the quarter. The APC’s allocation figure from the allocation 
database is combined with the monthly expenditure database for the selected 


fiscal year and quarter. 


e Expenditures for the month. This data is derived for each APC from the 
monthly expenditures database. 


The following numbered items, which clarify the calculated fields 
within the report, correspond with the numbers in Figure 29. 
l This is the fiscal year of the report. 


2 This is the month of the report. The numerical month requested is converted 
to the name of the month, i.e., month 10 becomes October. 


3 Quarter of the report. 

4 Report date provided by the system. 

5 Spent for Quarter. This field is calculated by summing all the monthly 
expenditures for the specified quarter. For instance, if the monthly report is for 
November, the system searches the monthly expenditure database and finds all 


expenditures for the first quarter's months; October, November, and December. 
(Note: in this example, December's expenditures would be zero.) 
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Figure 29. Monthly Budget Expenditure Report 
6 Flag Field. This field prints a "**" if the amount spent for the quarter or 
month exceeds the amount allocated for the quarter or month (see Note 8 below). 
This flag serves as a visual indicator to the reader and highlights probable 
problem areas. 
7 Percent Spent for Quarter. This field is computed by dividing the amount 
expended so far in the quarter (as determined in Note 5 above) by the allocation 
for the quarter. 


8 Funds per Month. This amount is computed by dividing the quarterly 
allocations by three to provide monthly allocations for the sections. 


9 Percent Spent for Month. This field is computed by dividing the amount 
expended during the month in question by the Funds per Month (explained in 
Note 8 above). 

(2) Quarterly Report. Figure 30 is an illustration of the quarterly 
budget expenditure report. This report serves as the Department Chief's indicator of the 
status of funds for the selected quarter. This report, like the monthly report, is critical 
in allowing the Department Chief to monitor the sections” compliance with the 


department's budget. This report is also provided to the section chiefs for the same 


Teason. 
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The quarterly report is designed to closely resemble the monthly 


report. This report remains in the same format as the monthly report, but excludes all 


the fields relating to monthly expenditures. 


The user is prompted to enter the fiscal year and the quarter desired 


prior to the output of this report. The fields required for each record are the same as 


described in Subsection (1) on the monthly budget expenditure report. 
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Department of Family Practice 
Quarterly Expenditure Report 


O 





Quarter Report Date 07750705 


APC INFORMATION QUARTER 


SECTION ALLOCATED SPENT PERCENT 
SPENT 





Month ppy Fiscal Year | 
E 





W140 PRIMARY CARE 4000.00 3000.00 75 $ 
W257 FAM FRAC CL 9000.00 9500.00 ** 106 % 
W360 EMERG MED SERVICE 30000.00 5000.00 1229 


DEPARTMENT TOTALS | 43000.00 17500.00 PET 


** Indicates an overexpenditure of funda. 


Figure 30. Quarterly Budget Report 


The following numbered items, which clarify the calculated fields 


within the report, correspond to the numbers in Figure 30. 


1 This is the Fiscal Year of the report. 


GA — [t9 


ES 


This is the quarter of the report. 
Report date provided by the system. 


Spent for Quarter. This field is calculated by summing all the monthly 


expenditures for the requested quarter. For instance, the system searches the 
monthly expenditure database and finds all expenditures for the selected quarter’s 


months, 


for each APC. 
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5 Flag Field. This field prints a "**" if the amount spent for the quarter exceeds 
the amount allocated for the quarter. This flag serves as a visual indicator to the 
reader and highlights probable problem areas. 


6 Percent Spent for Quarter. This field is computed by dividing the amount 
expended so far in the quarter (as described in Note 4 above) by the allocation 
for the quarter. This process is repeated for each APC. 


(3) Fiscal Year Allocation Report. Figure 31 is a representation of 
the Fiscal Year Allocation Report. This report shows the allocation for each APC for 
each quarter in the user selected fiscal year. This report also shows the percent change 
between the previous fiscal year’s allocation and the selected fiscal year’s allocation. 
This report provides the Chief with a quick look at the relative allocations for each of 


his sections compared with fund allocations from the previous fiscal year. 


FISCAL YEAR ALLOCATION REPORT 
O 


DEPARTMENT OF FAMILY PRACTICE 64 
COMMUNITY MEDICINE (TDA) 


es maa 
APC SECTION ALLOCATISN ALLOCATIO ALLOCATION ALLOCATION TOTAL FOR 
QOARTER 1X CHANGE QUARTER 2 N CHANGE QUARTER 3 CHANGE QUARTER 4 CHANGE FISCAL YR CHANGE 
MERE CEA : O RA RARA RS RE RA 


EA Y T PPS 


LE SSIES A E OEM ORO RoE REG EEE EERE BER EE RS 









W140 PRIMARY CARE 1000.00 516.00 516.00 518.00 2550.00 
W145 C, FAM PRAC 8000.00 2000.00 2000.00 2000.00 14000.00 
W357 FAM PRAC CLINIC 14000.00 -0.11 8000.00 -0.50 8000.00 -0.50 8000.00 -0.50 38000.00 -0.40 
Woof CTMS-FPC 10000.00 1.7] 6000.00 1.06 6000.00 1.06 6000.00 1.06 28000.00 1.24 






SECTIGNS —— 
p t 


70266.00 -0.39 70266.00 -0.39 70268.00 -0.39 330000.00 -0.29 





TOTALS 119200.00 1.04 


Figure 31. Fiscal Year Allocation Report 
The user is prompted to enter the fiscal year prior to the output 
of this report. The fields required for output of this report include: 
e APC. 


+ Section Description. 
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e Allocations. For each APC for the current year. 
e Allocations. For each APC for the previous year. 
The following numbered items, which clarify the calculated fields 
within the report, correspond with the numbers in Figure 31. 


1 This percentage reflects the percent change between the previous fiscal year’s 
allocation and the currently selected fiscal year allocation. 


2 Totals for the department. This number reflects the total allocation for the 
department for each quarter in the selected fiscal year. This figure is calculated 
from totaling all quarter allocations for all of the APCs within the APC 
Allocation Database. 


3 In the cases where an APC did not exist in a prior year, the percentage change 
field (as described in Note 1) is left blank. 


(4) Fiscal Year Recap. Figure 32 provides an illustration of the Fiscal 
Year Recap Report. This report serves as the Department Chief’s indicator of the year’s 
funds status for the department. This report is critical in allowing the Department Chief 
to analyze each section’s compliance with the imposed funds limitations. Throughout 
the year, this report can provide a quick look at the current status of funds remaining 


to fulfill the needs for the rest of the fiscal year. 





Department of Family Practice 
FISCAL YEAR RECAP REPORT 


Fiscal Year : Report Date : 7/20/89 


y 
APC INFORMATION | FISCAL YEAR 89 RECAP 
d 





SECTION ALLOCATED SPENT PERCENT UNDER COMMITTED OVER COMMITTED 
SPENT THIS re THIS feu 


W140 PRIMARY CARE 16419. 1091.43 1853245) 
W357 FAM PRAC CL 62600. Ac 2759.02" = T : 159.02 


W258 CTMC-EPC 15500700 5630.03 36 % 9869.97 
W360 EMERG MED SERV 124000.00 107972.58 Lo $ 16027.42 


** Indicates an overexpenditure of funds. 


Figure 32. Fiscal Year Recap Report 
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The user is prompted to enter the fiscal year desired prior to the 
output of this report. The fields required for output of this report include: 
e APC. 
e Section description. 
e Allocation for the quarter. 
* Expenditure for the month. 
The following numbered items, which clarify the calculated fields 
within the report, correspond with the numbers in Figure 32. 
1 Allocated Funds for FY. This number represents the allocation for each APC 
in the allocation database for the selected fiscal year. This number is computed 
by totaling all quarter’s allocations within the selected fiscal year for each APC. 
2 Total Spent this FY. This represents the total amount spent in the selected 
fiscal year for the APC . This number represents a total of all monthly 


expenditures for the selected fiscal year in the monthly expenditure database. 


3 Uncommitted Funds this FY. This number represents the difference between 
Allocated Funds for FY (Note 1) and Total Spent FY (Note 2). 


4 Over Committed this Fiscal Year. This column is printed when the 
uncommitted funds are negative in the preceeding column (Note 3). It serves to 


flag overcommited sections within the department. 


5 Percent Spent FY . This column is calculated by dividing the Total Spent this 
FY figure (Note 2) by the Allocated Funds for FY figure (Note 1). 


6 Department Totals. These numbers, with the exception of Percent Spent (Note 
5), are totals of the respective column above the numbers. The Percent Spent 
figure is the total spent for the fiscal year divided by the total allocated funds. 
(5) Percent Spent For Quarter Graph (see Figure 33). This report 
provides the Department Chief with a graphical portrayal of the funds remaining for 


each APC for a selected quarter. This graph provides a visual picture of the current 


status of all of the APC’s expenditures. 
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Department of Family Practice 
Percent Spent for Quarter 


APC SECTION 0% 20% 40% 60% 80% 100% |120% 140% 

PRIMARY CARE A e ` | ' ! | ! ' 

FAM PRAC CL 

CTMC-FPC 

FSO 

GOC 

POM-HC 4 

CTMC 

BN AID STATION - 
FHL-H 

CTMC (PATH) 

AMB SVC 

CTMC (IMMUN) 


BN AID STAT (IMMUN) - 
DEPARTMENT 





O% 20% 40% 60% 80% 100% 120% 140% 


ay MI PERCENT SPENT 


Figure 33. Percent Spent for Quarter Graph 
The user is prompted to enter the fiscal year and quarter desired 
prior to output of this report. This report requires the following fields to be completed: 
e APC. 
* Section description. 
* Total Expenditures for the quarter for each APC 
e Allocation for the quarter for each APC . 
The following numbered items correspond to the numbered items 
in Figure 33: 


1 The X-axis represents the APC’s expenditures for the quarter on a scale from 
O to 100 percent of the amount allocated for the section. 
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2 The actual computation of this percentage comes from dividing the total 
expenditures for a section by the allocation for that section. 


3 APC’s active in the selected quarter are reported along the Y-axis. 

(6) Trend Analysis Graph (see Figure 34). These two graphical pictures 
provide the Chief with a look at the current trend in expenditures for the current year 
and the trends for the two previous years. The expenditures are compared to the 
allocations for the respective fiscal years. This report will be used to report and track 
the overall budgetary trends within the department for the current fiscal year. This 
report can be called up at any time during the current fiscal year. 

The user is required to enter the fiscal year prior to output of this 
report. The data fields necessary to create this report include: 

* Total Allocation for all APCs for each quarter within the selected fiscal year. 

* Total expenditures for all APCs for each month within the selected fiscal year. 
This will not be graphed but serves as the building block for the graphing of 
this data on a cumulative basis. 

A calculated cumulative total for each of the above data fields is 
required to create these two graphs. As depicted in Figure 34, one line is graphed to 
represent the cumulative total of each quarter’s allocation. The second line represents 
the cumulative total expenditures for each month. 


The following numbered items correspond with Figure 34. 


1 This line reflects the cumulative total for the total allocations for all APC’s 
reported for the selected fiscal year in the APC Allocation Database. 


2 Each tick mark on the line corresponds to the actual total expenditure for all 
APCs for the given month on the X axis. 
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Department of Family Practice 
Fiscal Year 89 Expenditures 
D DOLLARS (Thousanda) 
300- FY 89 
250 - 1 
200 - 
150 - 












d 
OCT NOV DEC JAN FEB MAR APR MAY JUN JUL AUG SEP 
MONTH 


rr : Expenditures —*— Allocation 


(Q4 ——————e PERCENT OF TI 
3 (Current ae Kei? 





Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 
Quarters 





Figure 34. Trend Analysis Graph 
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3 This graph represents a long term trend analysis of department wide 
expenditures. The system uses the current fiscal year’s expenditures and the two 
previous year’s expenditures to create this graph 

4 The fiscal year of the information graphed. 

5 Quarter allocations are plotted on the FY graph by dividing the quarterly 
allocation into three equal monthly allocations (done within the department). 
These monthly allocations are then graphed on a cumulative basis. 


6 The percent of allocation is computed by dividing the expenditures for the 
month by the allocation for the month. 


24. Equipment Information System (see Program, Appendix D) 

Figure 35 is the UCD describing the proposed Equipment Information 
System. As shown in the diagram, initial equipment requirements are identified with 
the department's Resource Information Report (RIR). The RIR is shown in Figure 36. 
This report is completed by the sections and submitted to the department NCOIC. In 
addition to new equipment requirements, the RIR is also the medium for updating 
previously submitted equipment requirements. The information contained in the RIR 
is used by the department to update the equipment procurement database. As shown 
in Figure 36, the RIR is also the medium for collecting section personnel information, 
i.e., gains, losses, and changes. The personnel portion of the RIR is discussed in 


Section 3, Personnel System. 
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Figure 35. Equipment Information System User Concept Diagram 
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Figure 36. Resource Information Report (RIR) 
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a. Data Structures 
The Equipment System consists of two databases. The primary database 
maintains the active department equipment requirements and contains the following data 
fields: 


e Equipment Code Number. This number, assigned by the system, uniquely 
identifies each equipment item in the database. 


e Section Code. Explained in Section 1, Budget System. 
e Date of Request. The date equipment is requested by the section. 


* [tem Description. This is a short description of each equipment item identified 
in the database. 


* Type of Request. The equipment requested will be one of four types, 
MEDCASE, CEEP, CAPR, or other as described in Chapter IV. 


+ Priority. The priority number is a ranking of all of the equipment to indicate 
the relative priority of each. The Department Chief assigns the priority to all 
department equipment using the priority worksheet described in the Outputs 
section below. 


e Urgency Code. The urgency code indicates how soon the equipment is needed 
by the section. 


* Quantity. 

* Unit Price. 

* Extended Price. Quantity * Unit Price. 

e Status of Procurement. The status of the procurement is indicated by one of 


five codes to show where each equipment request is in the procurement 
process. The five codes and their meaning are listed below: 


PW Paperwork is being prepared by the section requesting the equipment. 
RM RMD is processing the equipment request. 

AP RMD has approved the equipment procurement. 

OO The section as put the equipment on order. 

RC The equipment has been received by the section. 


e Comments. 
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The second database maintains the historical information on equipment 


previously procured by the department and consists of the following data fields: 


Section Code. 

Item Description. 

Type of Request. 

Quantity. 

Extended Price. 

Date of Request. Taken from primary database described above. 


Transfer Date. The date the item was transferred to the historical database 
(upon receipt of the equipment). 


Months to Complete Procurement. The difference between the date of request 
and the transfer date. 


Comments. 
b. Data Inputs 


The Equipment System menu hierarchy chart is shown in Figure 37. 


The menu system allows the user to update the equipment database, print reports, and 


archive completed equipment procurements in the historical database. Users enter new 


equipment requirements into the primary equipment database using the input screen 


shown in Figure 38. This screen presents all of the data fields necessary for user input 


and displays the various codes needed for the specific data fields. 


To change or remove equipment from the database, the user selects the 


appropriate menu item and is then prompted to enter the equipment code number or 


the section code to identify the equipment to be changed or removed. If the user does 


not know the equipment code number, he or she can enter the section code. A list 


Iu 


EQUIPMENT SYSTEM 
Section 1 


MAIN 
MENU 


CONTINUED, SECTION 2 


UPDATE 
PRIORITY /STATUS 


UPDATE 
EQUIPMENT FILE 








ADD CHANGE RENOVE REVIEW UPDATE UPDATE 
EQUIPMENT INFORMATION EQUIPMENT EQUIPMENT PRIORITIES STATUS 
Cu BY MEDCASE BY 
EQUIPMENT CODE EQUIPMENT CODE PROCUREMENTS EQUIPMENT CODE 
BY BY CEEP BY 
SECTION CODE SECTION CODE PROCUREMENTS SECTION CODE 
CAPR 
PROCUREMENTS 
OTHER 
Section 2 
CONTINUED FROM 
SECTION | 
PRINT ARCHIVE 
REPORTS HISTORICAL 
DATA 
DEPARTMENT EQUIPMENT PRIORITY HISTORICAL EXPORT 





REPORTS TYPE WDRKSHEETS REPORTS TO SPREADSHEET 
REPORTS 
BY MEDCASE MEDCASE HISTORICAL CURRENT 
COST PROCUREMENTS PRIORITY FORM DATA REPORT DATABASE 
BY CEEP CEEP HISTORICAL HISTORICAL 
URGENCY PROCURENENTS PRIORITY FORM SUMMARY DATABASE. 
BY CAPR CAPR 
STATUS CODE PROCUREMENTS PRIORITY FORM 
OTHER OTHER 


Figure 37. 


Equipment Menu Tree 
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of all equipment requirements for that section is presented. The user is then asked to 
enter the record number (displayed to the left of each equipment item) of the desired 
equipment record to change. When changing equipment data, the user is presented 


with the same screen discussed above for new data entry. 


ENTER NEW EQUIPMENT 


EQUIPMENT CODE ¢ IBEB.N 


SECT DATE ITEM DESCRIPTION TYPE URGENCY QIY UNIT PRICE 


STATUS CODE COMMENTS 





URGENCY CODES TYPE OF REQUEST CODES STATUS CODES 


Needed Now MEDC MEDCASE PW Paperwork 


1] Year CEEP CEEP 
2 Years CAPR CAPR 
3 Years OTRE OTHER 
Not Urgent 


RM RMD Process 


AP Approved 
OO On Order 
RC Received 





Figure 38. Equipment Input Screen 
The user is allowed to update the priorities on the equipment list. 

Priority changes are obtained from the priority worksheet (discussed in the Output 
section below). The Department Chief reviews all equipment requests and completes 
the priority worksheet to identify overall department priorities. The database is then 
updated with the new priorities. After selecting the equipment, the user is presented 
with a review screen similar to that described in Section C of this chapter. The fields 
displayed correspond to the priority worksheet to simplify user input and are listed 
below: 

* Equipment Code Number. 

e Type of Request. 


« Section Code. 
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* [tem Description. 

e Urgency Code. 

¢ Priority. The Department Chief’s numerical ranking for the item. 

e Quantity. 

* Unit Price. 

The user is allowed to enter the changes directly to the review screen. 

When equipment status changes, e.g. an equipment requisition is submitted or 
equipment is received, the sections are required to indicate this on the RIR and submit 
it to the department NCOIC. These status changes are then entered into the database 
using the input screen shown in Figure 39. This screen is similar in format to the 


Status Update section on the RIR to simplify user data entry. 


SECTION 


EQUIP CODE ITEM DESCRIPTION Ory UNIT PRICE STATUS 
9010.01 BREAST PUMP 2 1300700 PW 


COMMENTS 





Press ESC to abort editing, ENTER to complete changes. 


Figure 39. Status Update Screen 
c. Outputs 
(1) Review Equipment List. The format of the review screen is 
discussed in Section B above. All of the equipment database fields are listed on the 
review output screen. The user can scroll left and right, up and down, to view or 


change all fields for each record. 
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(2) Department Equipment Report (see Figure 40). The department 
equipment report is a complete equipment requirements listing for the department. All 
of the fields in the equipment database are used to produce this report. The user is 
allowed to choose one of three sort options. The flexibility to select the sort option 
mikes it easier to highlight those aspects of equipment procurement most important to 
the Department Chief. Each sort option is discussed below: 


e Sorting by Cost. The equipment list is sorted by the extended price field, 
from high values to low. 


e Sorting by Urgency. The equipment list is sorted by the urgency code, from 
zero (0) for immediate equipment requirements to four (4) for non-urgent 
requirements. Within each urgency code section the equipment is further 
sorted by section code and extended price (from high to low). 


e Sorting by Status. The status sort option groups the equipment information 
by each of the five status codes. Each group is further sorted by section code 
and extended price (from high to low). 


TYPE SORT: Ne EQUIPMENT REPORT Doe 7/20/89 
zd UNIT |EXTENDED | ACCUMULATED 
SECT DATE DESCRIPTION PRICE | PRICE TOTALS  |STAT|COMMENTS 


9015.01 FFC 01/10/89 BEDPAMN MEDC e 5200.00 10400.00 10400.00 

9025.20 EMS 01/20/89 SPIT CUP OTHE 5 1000.00 5000.00 15400.00 oo BACKORD 
836.89 CIM 12/15/88 MICROCOMPUTER CAPR 1 3000.00 3000.00 18400.00 oo BACKORD 
9105.60 CFP 04/10/89 GAMMA CAMERA CEEP 1 1000.00 1000.00 19400.00 AP 





de wv Ut 
hn 


Figure 40. Department Equipment Report 
The following numbered items correspond to the numbers in Figure 
40 and explain certain portions of the report. 
l The system date is printed at the top of the report. 


2 The type of sort indicates how the equipment list has been sorted, by COST, 
URGENCY, or STATUS. 


3 The format of the fields listed across the top remains the same regardless of 
the sort option chosen. 
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4 The cumulative total is calculated by adding each successive extended price to 
the previous cumulative total. 


(3) Equipment Type Report (see Figure 41). The equipment type 
report is a listing of the equipment requirements for One of the equipment types, either 
MEDCASE, CEEP, CAPR, or OTHER. The user selects the type of equipment he or 
she wants listed from the menu. All of the fields in the equipment database are used 
to produce this report. The user is allowed to choose one of two sort options. Each 
sort option 1s discussed below: 


e Sorting by Cost. The equipment list is sorted by the extended price field, 
from high values to low. 


e Sorting by Priority. The equipment list is sorted by the priority code, from 
one for highest priority to the lowest existing priority in the database. Within 
each priority section the equipment is further sorted by section code and 
extended price (from high to low). 


TYPE eet D oe EQUIPMENT TYPE REPORT Q) DATE: 7/25/89 





| FPC 01/10/89 INSUFFLATOR 1 2 4800.00 8800.00 8800.00 

2 EMS 01/20/89 MICROTOME 2 S 4990.00 24950.00 33750.00 BS BACKORD 
3 CIM "12/15/88 FLORO=LITE T a 1149.00 1149.00 34899.00 oo BACKORD 
4 CFP 04/10/89 PLASMA BATH 1 1 1500.00 1500.00 36399.00 AP 


Figure 41. Equipment Type Report 
The following numbered items correspond to the numbers in Figure 
41 and explain certain portions of the report. 
l The system date is printed at the top of the report. 


2 The type of equipment indicates which equipment type is listed in the report, 
either MEDCASE, CEEP, CAPR, or OTHER. 


3 The format of the fields listed across the top remains the same regardless of 
the sort option chosen. 


4 The cumulative total is calculated by adding each successive extended price to 
the previous cumulative total. 
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(4) Equipment Priority Worksheet (see Figure 42). The priority 
worksheet is used by the Department Chief in a meeting with each of his section 
chiefs. In this meeting, the priority of all of the department’s equipment requirements 
is determined and annotated on the priority worksheets for each equipment type. These 


worksheets are then used to update the priorities in the equipment database. 


Type: oraen( 2) EQUIPMENT PRIORITY WORKSHEET G) Date 7/20/89 









9010.01 FPC MICROSCOPE o 1000.00 3000.00 
9020.02 FPC ULTRASOUND, PORT 1 : 2500.00 2500.00 
9045.10 FMS RRFAST PUMP 10 2 5 200.00 1000.00 
9020.07 CTM ENDOSCOPE 99 4 1 500.00 500.00 


Figure 42. Equipment Priority Worksheet 
The data fields necessary to produce the priority worksheet are 
listed below: 
e Type of Equipment. 
* Equipment Code Number. 
e Section Code. 
e Item Description. 
e Priority. 
* Urgency Code. 
* Quantity. 
* Unit Price. 
e Extended Price. 
* Comments. 
The following numbered items correspond to the numbers in 


Figure 42 and explain certain portions of the report. 
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1 The system date is printed at the top of the report. 


2 The type of equipment indicates which equipment type is listed in the report, 
either MEDCASE, CEEP, CAPR, or OTHER. 


3 A fill in section is provided to allow the Department Chief to enter the updated 
priorities. 


(5) Equipment Historical Report (see Figure 43). Once equipment 
is received, the data referencing it can be archived from the primary equipment 
database to the historical database. All of the historical database fields are used to 
produce the equipment historical report. The report can be sorted either by section or 
by equipment type. Within each of these sort options the list is further sorted by the 


extended price field, from high to low. 










TYPE SORT: SECTION EQUIPMENT HISTORICAL REPORT = DATE: 7/20/89 
mee Lm [m ees 
TYPE | DESCRIPTION PRICE DATE ESCH SEN COMMENTS 

FPC MEDC BEDPAN 10400.00 01/20/89 03/20/89 2 

FPC OTHE SPIT CUP S $000.00 03/20/89 05/25/89 2 

Subtotals 15400.00 

CIM CAPR MICROCOMPUTER it Jat 3000.00 04/13/89 05/13/89 1 

Subtotals 3000.00 

CFP CEEP GAMMA CAMERA m l 1000.00 11/12/88 02/12/89 4 

Subtotals 1000.00 


Figure 43. Equipment Historical Report 
The following numbered items correspond to the numbers in 
Figure 43 to explain the report information. 


1 The transfer date is automatically entered into the database using the system 
date when the data is archived. 


2 The months to complete the procurement are calculated by subtracting the 
transfer date from the original request date. 


3 Subtotals for each section or equipment type group are shown for the extended 
price field and is obtained by totaling the extended prices for the respective 


group. 
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(6) Historical Summary Report (see Figure 44). The historical 
summary report displays summary statistical information about the data in the historical 
database. The Department Chief can use the summary report to determine the 
department’s history of equipment procurement in terms of the number of equipment 
requests, average costs of the equipment requested, the type of equipment requested, 
and the average length of time to obtain equipment. The historical database fields 
necessary to create the summary report are listed below. 

e Section Code. 

* Type of Request. 

* Quantity. 

e Extended Price. 

* Date of Request. 

* Transfer Date. 

e Months to Complete Procurement. 

The following numbered items correspond to the numbers in 

Figure 44 and explain the method used to produce the summary report information. 


1 The earliest date of request and the latest date of request contained in the 
database are listed at the top of the report. 


2 The total number of requests for each type of equipment are calculated by 
adding the total quantities of equipment procured for each equipment type. 


3 The average cost of each equipment type is calculated by dividing the total 
extended price for the equipment type group by the total number of requests for 
that equipment type group. 


4 The average time to complete an equipment procurement is calculated by 


averaging all of the figures for the number of months to complete each 
procurement for each equipment type. 
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5 The total number of requests for each type of equipment is summed for each 
section. 


6 The average cost for each type of equipment is calculated for each section by 
dividing the total cost of the equipment type requests for a section by the total 
number of requests for that equipment type for the section. 


HISTORICAL SUMMARY REPORT 
(D EARLIEST REQ DATE: 1/13/88 


LATEST REO DATE: 7/20/89 
REQUESTS BY TYPE 3) 
TYPE REQUEST # REQUESTS AVG COST AVG MONTHS TO COMPLETE 
CAPR 29 7500.00 Sjo dl 
MEDC D 78 3500.00 220 
CEEF 52 11000.00 4.7 
$ REQUESTS BY SECTION 
SECTION $ MEDCASE $ CEEP $ CAPR $ OTHER 
FRC e 13 7 10 
CIM 14 11 6 E 
GOC d 2 0 2 
EMS 1 0 0 3 


AVERAGE COST BY SECTION 


SECTION AVG MEDCASE AVG CEEP AVG CAPR AVG OTHER 
FRC 4400.00 13000.00 8500.00 2900.00 
CIM 3700.00 9000.00 3400.00 3000.00 
GOC 3400.00 6500.00 0.00 2700.00 
EMS 3000.00 0.00 0.00 2650.00 


Figure 44. Historical Summary Report 
3. Personnel Information Svstem (see Program, Appendix E) 
Figure 45 is the user concept diagram for the personnel information system. 

This system interfaces the four major personnel subsystems identified in Chapter IV. 
These information subsystems include: 

* Department Personnel Information Subsystem (including personal data). 

* Table of Distribution and Allowances Subsystem. 

* Leave and Absence Recordkeeping Subsystem. 


* Continuing Medical Education (CME) Budget Subsystem. 
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Figure 45. Personnel Information System User Concept Diagram 
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The consolidation of all four personnel subsystems under one major system 
simplifies the transfer and maintenance of the six data files necessary to maintain the 
data. All personnel inputs, processing, and outputs are captured within a single series 
of operations without requiring the user to leave the current application environment. 

a. Data Structures 

Figure 46 depicts the various database files required to support the 
personnel information system. This figure shows how the file that represents a person 
within the department serves as the pivotal point for the interrelation of all of the 


personnel files. 


PERSONNEL DATABASE 


PERS LAST FIRST RANK BRANCH DOCTOR LOSS ARRIVAL P 
ID NAME NAME STATUS DATE DATE A 

CODE R 
Fm 


ABSENCE DATABASE | TDA INFO | INFO 


FERS FISCAL TYEE START END DURATION | COMMENT 
ID YEAR REQUEST DATE DATE 

CODE . 
* 


* CME REQUEST DATABASE 


* 
// 
PERS FISCAL TYEE START END DURATION OTHER 
ID YEAR {REQUEST DATE DATE DATA 
CODE FIELDS 


CME ALLOCATION DATABASE 


FISCAL CME 
YEAR FUNDS 
ALLOCATION 


PERSONAL DATABASE 


AE 
PERS ADDRESS| CITY STATE ZIP SPOUSE'S OTHER 
ID CODE NAME DATA 
CODE FIELDS 


TDA INFO TDA DATABASE 


OFFICIAL|ACCOUNT AUTH AUTH AUTH AUTH 
BRANCH GRADE MOS CODE 


Figure 46. Personnel Data Structures 
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The key field identified throughout the database is the Personnel 


Identification Code as described below. This code is already used in the current system. 


It is recognized as the method by which personnel data should be maintained 


throughout the department. 


The personnel file, which represents an individual assigned to the 


department, contains the following fields: 


Personnel Identification Code. This code is derived from the first letter of an 
individual’s last name, combined with the last four numbers of their social 
security number. 

Last Name. 

First Name and Middle Initial. 

Rank. 


Branch of Service (accepted military abbreviations e.g., Medical Corps (MC), 
Army Nurse Corps (AN), etc.). 


Military Occupational Specialty Code. 
Arrival Date within the Department. 
Anticipated Date of PCS (if known). 
Currently assigned TDA Paragraph Number. 
Currently assigned TDA Line Number. 


Currently assigned TDA Position Number. If the person is carried as excess, 
this number will be 99. 


Doctor Status (if appropriate). This code serves to track only the current 
training status of doctors in the residency program. The codes used are; (1) 
Third Year Residency, (2) Second Year Residency, (3) First Year Residency 
(Student). 
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The personal information database file serves as the repository of 


sensitive information about an assigned individual. Each record contains: 


Personnel Identification Code. This code serves to relate this file to the 
personnel file. 


Local Home address. 

City of Home address. 

State. 

Spouse’s first name (if appropriate). 

Children’s names, followed by their ages (if appropriate). 
Home telephone number. 

Date of rank. 

Personal Comments. 


The Table of Distributions and Allowances (TDA) database file reflects 


the current positions available as obtained from the most up to date TDA for the 


department. Each record contains the following fields: 


TDA Paragraph Number. 

TDA Line Number. 

TDA Position Number. 

TDA Official Job Title. 

The APC that relates to this particular position. 
The authorized branch of service of this position. 
The authorized rank or grade for this position. 


The authorized Military Occupational Specialty for this position. 
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Authorized field. This field is used to determine if the position is an 
authorized position under the current TDA. This position could actually be 
required under the TDA but not authorized under peacetime conditions. This 
is a common occurrence in TDAs in the military. 


The Continuing Medical Education funds allocation database records the 


CME allocation for each fiscal year. Each record contains the following fields: 


Fiscal Year. 
Allocation for the fiscal year in dollars. 


The Continuing Medical Education request database records the doctors’ 


requests for CME funded education. Each doctor can have several active CME requests 


within this database. Each record contains the following fields: 


Personnel Identification Code. 

Fiscal Year of the request. 

Type Request. The CME request can be one of the following types of 
requests: (C) Conference/Meeting Travel, (G) General Mission Travel, (B) 
Board Certification. 

Start Date of Travel. 

End Date of Travel. 

Duration of travel. This field is computed by determining the number of days 
between the start date and the end date. This data is used in the statistical 
summary reports described in Section 3.c, Outputs, below. 


Location or Destination. 


Purpose of travel. The title of the conference or the specific purpose of the 
request. 


Travel Mode. Travel can either be by (A) aircraft, (P) privately owned vehicle, 


or (G) government provided ground transportation. This is used in the 
computation of the costs involved in the travel. 
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Travel cost (Actual or estimated cost depending on the Costing Code described 
below). 


Per Diem Cost (Actual or estimated cost depending on the Costing Code 
described below). 


Registration Fee for the Conference (Actual or estimated cost depending on 
Costing Code described below). 


Reimbursable expenses (Actual or estimated cost depending on Costing Code 
described below). 


Total Cost of travel. This field is calculated by adding the Travel cost, Per 
Diem cost, Registration Fee, and Reimbursable expenses fields (Actual or 
estimated total cost depending on the Costing Code of the related fields). 


Costing Code. This code differentiates between an estimated total cost and the 
actual costs. The actual costs are identified once the travel has been completed 
and the travel claim voucher is received by the department. 


The Absence database maintains the record of all requested leaves or 


other absences, e.g., permissive TDY, emergency leave. This database does not record 


the CME requests discussed in the CME request database section. Each record contains 


the following fields: 


Personnel Identification Code. 

Fiscal Year of request. 

Type of request. (L) Ordinary Leave, (P) Permissive TDY, (E) Emergency 
Leave, (S) Sick Leave or Convalescence leave, (T) Temporary Duty, or (O) 
other type of unspecified absences. 

Start Date of Absence. 


End Date of Absence. 


Duration of absence. This field is computed by determining the number of 
days between the start date and the end date. 


Comments on special circumstances. 
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b. Data Inputs 
The Personnel Information System menu hierarchy chart is shown in 
Figure 47. This menu system allows the user to update the personnel system databases 
in the following areas: 
e Add, change or remove records in the personnel and personal database. 


e Add, change or remove records in the Table of Distributions and Allowances 
database. 


e Update the Personnel Files from information provided on the Resource 
Information Report explained in the equipment information system Section (2). 


e Add, change, or remove records in the Continuing Medical Education request 
and funds allocation databases. The user can also print the two required reports 
for CME fund monitoring. 

e Add, change or remove records from the absence database. 

The following sections describe the major data entry requirements for 
the personnel system. The common data entry requirements are described in the first 
section. This description is followed by the data input requirements for each of the 
major input submenus depicted in Figure 47. 

(1) Common Input Requirements. In most of the submenus, the user 
is required to enter a personnel identification code (PIC). The standardized entry screen 
discussed in Section C.2.a, Input Screens, is used for this input. The system then 


verifies the PIC entered against the personnel file. If the PIC is found in the database, 


the user is presented with the following confirmation screen. 


133 


1530038 382 1Y 


















ANv Iu ns 
3ON3S&v MINIY 
180438 1S3N03Y 3N0 
3ON3SO8YV 313130 
u31SOu SNOWUSOd VOL NOUVO JINI 
SE S3SN3dX3 3D 1S30034 32 MIA METE 
NUN JONVHO 
SNUS S1S3n0345 NOLUSOJ YA NOSYUId 
AONYOVA MARY SISNIAX3 39 183038 INO MƏN YVON — 
Q31VNUSJ Qv 
180d39 S1ISINO3IY SNOLUSOd YOL NOI 0 val NOU 
sso1 JAON An NOU IVO JNI VINO JN 
SIS) "RON HUM 
UYAN JINYHI JONVHO 
133HSAYOM S1S3n038 PA p eee ' 
INI 
HAGEN JONVHD S3SS01 NOLISOd VOI LINNOSY IA 
DNUS S1S3NO3IY MIN DO SC E 
NOWISOd 831N3 
190038 
JINISEV ONY CE YY n034 31YOdn ISP vai ISN 3NNOSY3d 
eae um ADO UYON HYUN 
č NOIL2JS C NOILJJS 'OJNNILNOJ 1. NOLLOJS £ NOU23S. 'OXMUNOO 
WO&4 GINNUNOD 
ANA MNOYJ AINNUNOD 
ANN ANAW 
NIV NIV 
NI VIA 
€ uOn»es 
Z uos caso 


W3lISAS I3NNOSH3d W3LSAS 1INNOSY A 


W3ISAS TINNOSY dd 


Figure 47. Personnel System Menu Hierarchy Chart 
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THIS IS THE PERSON WHOSE ID CODE IS MS 
LAST NAME BO FIRST NAME BS RANK 9 
OCCUPYING TDA PARAGRAPH Bg. LINE gg. POSITION gg 


««««««««SYSTEM MESSAGE DEPENDING ON TYPE OF REQUEST>>>>>>>> 


This confirmation screen allows the user to determine if the 
requested PIC is correct. This type of confirmation prevents the user from entering a 
wrong or inappropriate PIC that would destroy the integrity of the database. If the 
identification code is not found, a warning, "ID Code not found! Press return to 
continue...", is displayed. The system then gives the user the option to search for a PIC 
by entering the last name of the person. All records with the requested last name are 
displayed as shown below and the user is allowed to pick the identification code of the 
correct person from the list. 
LAST NAMEFIRST NAMEID CODE 
SMITH JOHN E. $2356 
SMITH BECKY K. S9999 
ENTER THE ID CODE OF THE PERSON DESIRED: Em 
An appropriate modification to this screen, if supported in the 
application program, would be the ability to select a record by highlighting the record 
desired and pressing the retum key. This process would eliminate the possibility of 
keying errors being introduced by the user. 


If the user is requested to enter information on a TDA position, 


the screen shown below is presented to the user. 
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WHAT POSITION WILL THIS PERSON OCCUPY 
OR ENTER A ZERO (0) TO QUIT 


TDA Paragraph Number JEEN 
TDA Line Number an 
TDA Position Number Bg 

Another feature that would enhance this input would be the addition 
of the ability to call up all TDA positions that are unoccupied. The user would then 
be allowed to select a TDA position by highlighting a particular position from among 
those depicted on the screen. This enhancement will make the following two screens 
unnecessary. 

The system then verifies the requested TDA position with the TDA 
database and if the position is found to exist in the database, the user is presented with 
the following standard TDA position screen. 

POSITION CHOSEN: 

Job Tile: Es 

Authorized Branch : I Authorized Grade : 

Authorized MOS — : mE Authorized Position : YES 
This screen also converts the authorized position field from its coded value to the 
correct YES or NO answer depending on the contents of this field. 

In the cases where a TDA position is requested and is found to 
already be occupied by someone else, the warning screen shown below is presented to 


the user. 
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THE POSITION IS ALREADY OCCUPIED BY: 


Last Name : 

First Name : MS 

Rank ` aan 

The user is then given the following choices. 

YOU NOW HAVE THE FOLLOWING CHOICES: 
1. MOVE THE PERSON FOUND IN THE POSITION TO EXCESS (POSITION 
CODE 99) AND THE PERSON YOU ARE WORKING WITH INTO THE 
POSITION YOU ORIGINALLY REQUESTED. 


2. PLACE THE PERSON YOU ARE WORKING WITH INTO THIS 
POSITION AS EXCESS (OVERSTRENGTH, POSITION CODE 99). 


3. TRY ANOTHER POSITION. 
ENTER YOUR CHOICE (1-5 : B 

(2) Enter, change, or remove personnel from the personnel database. 
As discussed earlier, the user is first requested to enter the identification code of the 
individual to add, change, or remove from the personnel file. In all of these cases, the 
system first checks the personnel file for the requested identification code. If the code 
is already in use, and the user is trying to enter this identification code to add a new 
person to the personnel file, the standard confirmation screen is displayed with the 
message "ID CODE REQUESTED IS ALREADY USED BY THE PERSON SHOWN 
ABOVE" and the user is prompted to try a different code. When the user is updating 
or removing someone already in the personnel file, this PIC check serves to confirm 


the identification code already exists in the file and warns the user if it is not found. 


E 


If the identification code is not found, the system gives the user the same options as 


described in the general input screens discussed earlier. 


UPDATE PERSONNEL 


ID CODE is W1456 


|! Last Name First Name MI BRANCH MOS 


Arrival Date Anticipated Date of Loss.. RBR BAB B 





INDIVIDUAL IS ASSIGNED TO TDA POSITION 


TDA Paragraph Number is 250 


TDA Line Number is 10 
TDA Position Number is 99 





NOTE: If Position Number is 99, the Individual is carried as excess 
Figure 48. Personnel Input Screen Format 

If the user is adding or changing information in the personnel 
database, the system requests the new position before displaying a blank data entry 
screen format. This action allows the system to verify that the TDA position is valid 
and is not already occupied by someone else. If the position is occupied, the standard 
choice screen as discussed earlier is displayed and the user must choose an appropriate 
course of action. Once they have selected a course of action, the system then allows 
access to the personnel database. The screen depicted in Figure 48 is the standard input 
screen for personnel information. This screen does not allow the user to either change 
the identification code or the position information, thus preventing the user from 
circumventing the integrity checks already accomplished by the system. 

Once the user has entered information into the personnel file, he 


or she is given the choice to enter data into the personal file. This data entry format 
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is displayed in Figure 49. This screen includes the privacy act statement to remind the 


user of the sensitive nature of this information. 


This is the personal information for ID CODE S7395 


PRIVACY ACT STATEMENT 
PRINCIPLE PURPOSE: To maintain personal information on individuals assigned to 


this command to facilitate counseling, emergency notification, and social 
event information. 


WARNING: This information is of a highly sensitive nature and should not be 
provided to anyone outside of the chain of command without approval. 


Address A MN A Telephone RE O ENE 
City, State, Zip Code  MNNENEEEBEEEEENENE. NE N 
Date of Rank Y Y | 
Wife’s Name MS Children’s Names/Ages [3s 
Comment s MA GN: 









Figure 49. Personal Information Data Entry Screen 

If the user desires to delete someone from the personnel database, 
the identification code entered by the user is used to find the right record. The screen 
depicted in Figure 48 is displayed with the message, "IS THIS THE PERSON YOU 
WANT TO DELETE? (Y/N)" E ", included p the screen. This allows the user to 
confirm the information about the person they desire to delete. If the user deletes the 
person, the system then purges all the files in the personnel system which have the 
requested identification code. Several databases are affected: the personnel database; the 
personal database; the CME request database; and the absence database. 

(3) Enter, change, or remove TDA information. The user gains access 
to the TDA database by initially entering the position they desire to add, change or 
remove in the position entry format described earlier. In the case where the user is 
adding a new position, this information allows the system to verify that the TDA 


position requested does not already exist in the database. If the user is modifying an 
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already existing TDA record, this information is used to locate the record or warn the 


user that the position entered does not exist in the database. 


TABLE OF DISTRIBUTION AND ALLOWANCES 


TDA Listing 











Paragraph Number 258 POSITION TITLE 


Job Title  MENEREEMENISEEENEE: 





Line Number 10 








Position Number 01 


POSITION CHARACTERISTICS 


APC Code 
Authorized Branch 
Authorized Grade 


Authorized MOS 
Position Authorized 
1=YES O=NO 





Figure 50. Table of Distribution and Allowances Input Screen 

The system must determine the authorized status of the position. 
If the position is new to the database, the user is required to answer the prompt, "IS 
THIS AN AUTHORIZED POSITION? (Y/N) § ". If the user answers yes, the system 
automatically replaces the authorization code with a one, otherwise the code is replaced 
with a zero. If the user is modifying an already existing database, the system uses the 
existing code to ask the user if they desire to change the current authorized status to 
the opposite status. For instance, if the authorized code is zero (0) (unauthorized), the 
message, "DO YOU WANT TO CHANGE THIS POSITION TO AN AUTHORIZED 
STATUS? (Y/N) § ", is displayed. 

If the user desires to delete a position, the format depicted in 
Figure 50 is used, but it includes a message to verify if the user desires to delete the 


displayed record. If the record is deleted, the system also checks the personnel database 
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to determine if someone occupies the deleted position. If a matching position is found 
in the personnel database, the person’s TDA position information is blanked in their 
record, and the following message is displayed. 

FOUND CPT SMITH OCCUPYING THE DELETED POSITION! 

ID CODE IS $2345 . BE SURE YOU UPDATE THIS PERSON’S 

TDA POSITION WITH A VALID TDA POSITION. 

(4) Update from Resource Information Report. This menu choice 
provides the user with the capability to directly update the personnel database with 
information provided in the Resource Information Report personnel sections. Figure 
51 depicts this input screen. The svstem also verifies the new position entered to 


ensure that it is not already occupied. and if it is occupied, responds with the screen 


of choices discussed earlier. 


UPDATE FROM R.I.R. REPORT 
B. CHANGES TO CURRENT TDA (OTHER THAN LOSSES OR GAINS) 


OLD POSITION NEW POSITION 





PRESS ESCAPE [ESC] TO QUIT 


Figure 51. Update from RIR Report screen. 

When the user is updating from the personnel losses section on 
the RIR, the user must first enter the PIC. This code is verified in the manner 
discussed earlier. The system then prompts the user with, "HAS THIS PERSON 
ACTUALLY DEPARTED OR IS THIS AN UPDATE TO A PROJECTED LOSS 


DATE? (ACTUAL=0, PROJECTED=1) M." If the change is a modification of the 
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anticipated loss date, the user enters the new loss date, and the record is updated 
automatically. If the loss is an actual PCS from the department, the system invokes the 
same procedures as described for the deletion of personnel in Section (2) earlier. 

(5) Enter, change, or remove CME requests. Figure 52 depicts the 
standard input screen for the CME request. This screen is designed to match the format 
of the actual printed CME request form used. The bottom of the screen is used to 
depict whether the costs displayed are actual expended costs or estimated costs. If the 
user desires to change an already existing record, the user must first enter the fiscal 
year of the request and the PIC code of the person sought. As discussed earlier, the 
confirmation screen displays the personnel information about the selected PIC with the 
message, "IS THIS THE PERSON YOU EXPECTED? (Y/N) E" The system then 
displays all matching records in the following format: 

RECORD NO. ID CODE TYPE START DATE END DATE 

5 S7777 C 06/07/89 07/07/89 

15 $7777 G 07/20/89 07/22/89 

ENTER THE RECORD NUMBER DESIRED : mu 
The user is then prompted with, "WILL COSTS BE ACTUAL COSTS OR 
ESTIMATED COSTS? (ENTER AN A FOR ACTUAL OR AN E FOR 
ESTIMATED):§." The system takes the user's response and enters the correct cost 
code into the record. The system will also total all travel costs and update the total 
cost of travel field in the record. 

In the case where the user only wants to update a record with the 

actual costs and selects this option in the menu, the system displays the same screen 


in Figure 52, except the user can only input the cost portions of the screen format. The 
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system then changes the cost code and totals the costs for the user prior to updating 


the record. 


| SUBJECT: APPLICATION FOR CONFERENCE/MISSION TRAVEL IN FISCAL YEAR 89 | 


1. Type of Travel Requested....... 
C-Conference/Meeting Travel G-General Mission Travel B-Board Certification 


2. ID CODE of person requesting the travel is $7396 


5. Registration Fee SB. 


Mode of Travel is J 
F-FLY, G-GOVT VEH, P-POV, O-OTHER 


P. Leave Dates Starting Date MEM NE Ending Date M/M 


4. Purpose of Travel is 





P p Rue SW D e 
UCA RE A 


6. Destination 








Duration O days 
13. TRAVEL COST Si. i PER DIEM COST SE IN REIMBURSABLES SEM. 
TOTAL -COST OF TRAVEL $ 0.00 


EXPENSES REFLECT THE ESTIMATED COST OF TRAVEL 


Figure 52. Continuing Medical Education Request Data Entry Screen 

Figure 53 depicts the input screen used to add, change or remove 
the records in the CME allocation database. There is only one CME allocation for the 
department for each fiscal year. Therefore, the user is always required to enter the 


fiscal year prior to using this screen to enter the CME funds allocation. 


UPDATE CME ALLOCATION 


THE CME ALLOCATION FOR FISCAL YEAR 89 SHOULD BE $ 





Figure 53. CME Allocation Data Entry Screen. 

(6) Enter, change, or remove leave/absence requests. Figure 54 depicts 
the data entry screen for the absence database. Prior to using this screen, the user must 
fist provide the fiscal year of the request and PIC of the person who will be entered. 


Once the PIC is entered, it is verified against the personnel database and if it is found, 
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the standard confirmation screen is displayed with the message, "IS THIS THE 


PERSON YOU EXPECTED? (Y/N)'. 


UPDATE LEAVE OR ABSENCE REQUEST 


This is the Fiscal Year 89 Leave or Absence request for ID CODE S7396 


Type of Request J 


L..Regular Leave E..Emergency Leave T..Other TDY, not “ENE 





P..Permissive TDY C..Convalescent Leave O. Other 


Starting Date E EHE B Ending Date M HE E 
Duration 0 days 


COMMENT 





Figure 54. Leave and Absence Data Entry Screen 
If the user is changing an already existing record, the system uses 

the PIC entered to display the following: 

RECORD NO. ID CODE TYPE START DATE END DATE 

5 S777] C 06/07/89 07/07/89 

15 $7777 G 07/20/89 07/22/89 

ENTER THE RECORD NUMBER DESIRED : 
Since the PIC has already been verified with the confirmation screen, only the PIC 
number is displayed. The user can then choose the record desired. As discussed 
earlier, the ability to "point and shoot" to a particular record would enhance the user's 
ability to request a particular record. The record is redisplayed in the same entry 
format depicted in Figure 54. 


With each addition or change of a record, the system automatically 


recomputes the duration field by subtracting the starting date from the ending date. This 
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constant updating insures that this field will always be updated prior to saving the 
database. 
c. Outputs 

(1) Review Screens. The review of the personnel, TDA, absence, and 
CME request databases are accomplished by the use of the standard review screen. 
Each review option provides the user with the generic review display described in 
Section B of this chapter. The data fields presented, with the exception of the CME 
request database and the absence database, are simply the fields existing in the 
database. The CME request database and absence database are combined with the 
personnel database to create a new temporary database that contains the name 
associated with each PIC in the databases. The additional review fields displayed with 
the already existing fields in the CME request or absence database are the Rank, First 
Name, and Last name of the person that matches the PIC field in the CME or absence 
databases. 

(2) Position Listing (see Figure 55). This report provides the Chief 
with a listing of all TDA positions within his department and the personnel assigned 
to those positions. This report is generated by combining the TDA database with the 
personnel database where the TDA position in the personnel database matches the TDA 
position in the TDA database. If no match is found, the TDA information is printed 
but with the personnel information left blank. If the person is carried as excess, their 
information is also printed but with only the TDA paragraph number, TDA line 
number, and the excess position code of 99. This report is sorted in TDA paragraph 


number, line number, and position number order whether the position is filled or not. 


145 


DEPARTMENT OF FAMILY PRACTICE 4 COMMUNITY MEDICINE (TDA) 








11 MAR 88 
PARA UNE| POSN GR MOS BR JOB TITLE RANK/NAME AUTH STATUS 
+ 
DEPARTMENT OF FAMILY PRACTICE (DEP 
$31 01 01 06 61H00 MC C, DEPT FP LTC s6000424934 Y 
$31 02 01 EL 91850 EL CLINIC NCO MSG seras tasas Y 
= 02 " MSQ 184999] 
03 os 00318 as SECT (T/S) MS. SONUIHHESOEUS 
PARAGRAPH TOTAL ** AUTHORIZED :03 ASSIGNED : 04 SG) 
FAMILY PRACTICE CLINIC (FPC) 
532 01 01 61H00 MC FAW PHYS LTC apeveasese Y 
532 02 01 Da 61H00 MC FAM PHYS MAJ veeegeeseg Y 
832 02 02 04 41H00 MC FAM PHYS LTC eel Y 
532 02A 01 03 $1H00 MC FAM PHYS CPT eel Y 
$32 02A 02 03 61H00 MC FAM PHYS MA weegeeeeg Y 
532 02A 03 03 $1H00 MC FAM PHYS LTC weegeeeeg Y 
532 02A ee 03 MA. wee (8) cb e 
532 03 01 03 61H00 MC FAM PHYS CPT seeaeesune Y o; 
$32 03 02 03 61H00 MC FAM PHYS CPT #ttttttttt Y 1 
532 03 o3 03 $1H00 MC FAM PHYS CPT seeaeenuan Y 1 
532 o3 = oS 61H00 MC FAM PHYS CPT esas Y 1 
532 03 os 03 61H00 MC FAM PHYS CPT seee Y 1 
532 03 06 03 61H00 MC FAM PHYS CPT nesesita Y 1 
532 03 07 03 61H00 MC FAM PHYS COL Gg Y 2 
532 03 08 03 61H00 MC FAM PHYS CPT tetra Y 2 
532 03 09 03 61H00 MC FAM PHYS CPT sdittiHpHHHI 2 
§32 03 10 03 61H00 MC FAM PHYS CPT eessen 2 
532 03 11 03 61H00 MC FAM PHYS CRT Geeegëeg 2 
532 03 12 03 81H00 MC FAM PHYS CPT kii 2 
532 03 13 03 61 HOO MC FAM PHYS *VACANT* 
532 03 14 03 61HOO MC FAM PHYS "VACANT* 
532 04 01 04 66HOO AN HEAD NURSE CHT SE Y o 
532 05 01 03 66H00 AN MED SURG NUR ILT VAtestetinee Y 
532 05A 01 Ee 71L30 EL ADMIN SUPV MSG Steg Yy 
532 06 01 ES 91830 EL CLINIC NCO MSG ERE Y 
§32 07 01 ES 91B20 EL MED SP SPC sSSUiHENTHEN Y 
532 08 01 ES 91420 EL MED SP SPC ie Y 
532 09 01 E4 91A10 EL MED SP SPC 9S43HEHNHIHCN Y 
532 09 02 Es 91A10 EL MED SP SPC RMMEDIETHEHEI(GN Y 
532 10 01 E3 91A10 EL MED SP PEC HibiiiibibHEN Y 
§32 10 02 E3 91410 EL MED SP PFC s584H4HHENTHEN Y 
532 10 99 EXCESS PFC setaneuene Y 
§32 12 01 03 00679 GS MED CLK M) MS. seeeeenuas Y . 
532 12 02 03 00679 GS MED CLK (T) *VACANT* Y 
532 12 03 03 00679 as MED CLK (T) MS. 9493HH68339H98 Y 
$532 88 01 03 81H9D MC FAM PHYS CHT Gg Y 3 
532 DE 02 03 81H9D MC FAM PHYS CHT GE Y 3 
532 88 03 03 81H9D MC FAM PHYS CPT s24HtittttHtienm Y 3 
532 88 04 03 61H9D MC FAM PHYS CPT kein Y 3 
532 88 os 03 $1H9D MC FAM PHYS CPT seanteeune Y 3 
532 88 06 03 81H9D MC FAM PHYS CPT esas Y 3 
532 Be 07 03 $1H9D Mc FAM PHYS CRT See Y 3 
532 88 06 03 81H90 FAM PHYS CPT UY Y 3 
PARAGRAPH TOTAL ** AUTHORIZED 26 ASSIGNED : 37 
DIDICATES A 80 DAY AMTICIPATED LOSS 


: 
E 
! 
i 
E 
l5 
: 
3 
E 


Figure 55. Position Listing Report 


The fields necessary to create this report are: 


Section Description for each TDA Paragraph Number. 
TDA Paragraph Number. 


TDA Line Number. 
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¢ TDA Position Number. 

e Authorized Grade for above TDA position. 

e Authorized MOS for the above TDA position. 
* Authorized Branch for the above TDA position. 
e TDA Official Job Title. 

e Rank. 

e Last Name. 

e Authorization Code for the position. 


e Doctor Status Code. This code reflects the current residency status of a doctor 
in the residency program. 


e Anticipated date of PCS for the person in the position. 
The following numbered items correspond with the numbers in 

Figure 55. 

1 This section title correlates to the TDA paragraph number in the TDA. 

2 This subtotal is the total authorized positions within the TDA Paragraph 

number. This is calculated by totaling the authorized position fields for each 

paragraph number. 

3 This is the number of persons assigned to a particular TDA paragraph. This 

number is calculated by counting the number of TDA positions where the name 


field is not blank within the same TDA paragraph number. 


4 If no name is associated with a TDA position, the phrase "VACANT" is 
printed in this field. 


5 The doctor status codes in the database. They are also explained in a footnote 
at the bottom of the report. 


6 The RANK, FIRST NAME and LAST NAME of the person who occupies a 
TDA position are concatenated to produce this field. 
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7 This total is the total for the department and is a total of all the TDA 
paragraphs subtotals. 


8 Personnel whose position code is designated as 99 do not have a job title since 
they are carried in an excess capacity. 


9 This "*" flag indicates that the person listed has an anticipated loss date that 
is less than 60 days from the current system date. 


(3) Section Update Worksheet (see Figure 56). This worksheet allows 
the department to update its personnel database with new position information, changes 
or additions to the anticipated loss date field, and changes to the personnel status field. 
This report is very similar to the position listing with the exception of the following: 


e Each paragraph within the TDA is printed separately to facilitate individual 
delivery to sections. 


* There are three fill in the blank fields added to allow the section to directly 
annotate changes into the worksheet. 


This report is created from the same combination of databases 
necessary for the personnel listing, but only the following fields are needed to print 
this worksheet: 

e Section Description for each TDA Paragraph Number. 
e TDA Paragraph Number. 

e TDA Line Number. 

e TDA Position Number. 

e TDA Official Job Title. 

e Rank. 


e Last Name. 
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e Doctor Status Code for the person who occupies the TDA position. (Only 
applies to doctors in the residency program). 


e Anticipated date of PCS for the person in the position. 


SECTION WORKSHEET 
DEPARTMENT OF FAMILY PRACTICE & COMMUNITY MEDICINE (d? 
11 MAR 88 


"H 
» 


RA LINE  POSN JOB TITLE RANKNAME STATUS ALOSS NAME 


ILY PRACTICE CLINIC (FPC) 


STATUS/ALOSS 






` 


632 01 01 FAM PHYS LTC A 07/20/79 
832 02 01 FAM PHYS MAJ Agarre (2) 9999/99 
532 02 02 FAM PHYS LTC MIRRA Seva eo 
532 02A 01 FAM PHYS CPT btt. Gig X 
632 02A 02 FAM PHYS MI mitis 07/20/79 
532 02A os FAM PHYS LTC MI 

532 02A 99 MAJ didi 

5832 03 01 FAM PHYS CPT iia 1 

§32 09 02 FAM PHYS CPT Ai 1 

632 o3 o3 FAM PHYS CPT Alida 1 

632 os 04 FAM PHYS CPT Gë 1 

632 03 05 FAM PHYS Lei ag TTT 1 08/10/90 
532 03 06 FAM PHYS CPT Aiaia { 

§32 03 07 FAM PHYS COL sienna 2 

§32 03 08 FAM PHYS CPT Aida 2 

632 03 09 FAM PHYS CPT adie 2 

632 03 10 FAM PHYS CPT Zëtteg 2 

532 os 11 FAM PHYS Lei ag TTT 2 

632 03 12 FAM PHYS O a 2 

532 o3 13 FAM PHYS "VACANT? 

632 o3 14 FAM PHYS "VACANT* 

532 04 01 HEAD NURSE CPT Aida 

§32 05 01 MED SURG NUR LT féddedeeese 

632 05A 01 ADMIN SUPV MEC RRA 

632 06 01 CLINIC NCO MSG Adatti 

532 07 01 MED SP A 

532 08 01 MED SP SPC. Ibid. 

532 09 01 MED SP BPC Samain 06/29/91 
632 09 02 MED SP BPE Il 

632 10 01 MED SP PEC Gii miit 

532 10 02 MED SP PEC eg 

632 10 99 PFC gedet 

532 12 01 MED CLK M) MO li itl 

532 12 02 MED CLK (T) “VACANT” 

532 12 03 MED CLK (T) MS. iets: 

632 ag 01 FAM PHYS CPT saben 3 

632 88 02 FAM PHYS CPT tenes 3 

§32 88 03 FAM PHYS CPT Ai 3 

532 88 04 FAM PHYS CPT Atti 3 

632 88 05 FAM PHYS CPT plis. 3 

532 88 08 FAM PHYS CPT iii 3 

632 8s 07 FAM PHYS CET TTT 3 

532 ag o8 FAM PHYS CPT iii 3 





PARAGRAPH TOTAL *”  AUTHORIZED : 26 ASSIGNED : 37 


(1) - eg YEAR RESIOEMCY (2) - 2rd YEAR REBIDENCY (3) - 18T YEAR REBIOENCY (STUDENT) 





Figure 56. Section Update Worksheet 


The following numbered items correspond with Figure 56. 


] These fields are intentionally left blank to allow the section to input changes 
to the current TDA position listing. 


2 The RANK and LAST NAME of the person who occupies a TDA position 
are concatenated to produce this field. 
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(4) Loss Report (see Figure 57). This report provides the department 
with a listing of all personnel who have an anticipated PCS date between two user 
specified dates. Prior to printing this report, the user is required to enter these dates 


to define the parameters for which this report will be printed. 


LOSS REPORT 
DEPARTMENT OF FAMILY PRACTICE & COMMUNITY MEDICINE 


Q 11 MAR 89 
START DATE : 06/01/89 ENDING DATE : 09/25/89 


The following personnel have expected anticipated loss dates within the 
above dates: 


RANKNAME SECTION PCS DATE 
CPT JOHN SMITH AMB 07/01/89 
CPT JANE DOE CTM 09/01/89 
MSG GERYJONES CTM 07/09/89 
1LT WAYNE SHARPE FPC 07/20/89 


Figure 57. Loss Report 
This following fields are necessary to print this report. 
e Rank. 
* Last Name. 
e Section Description for the person. 
e Anticipated Date of Loss. 
The following numbered items correspond with Figure 57. 
1 The date parameters for the report entered by the user. 


2 The date in this field must lie between the parameter dates established by the 
user. 
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(5) Vacancy Listing (see Figure 58). This report provides a listing 
of all TDA positions within the department that are vacant. This report provides the 
Chief with a quick look at his personnel shortages and the current vacant positions 


within the department. 


-— 


VACANCY REPORT 
DEPARTMENT OF FAMILY PRACTICE & COMMUNITY MEDICINE 
11 MAR 89 


The following TDA Positions are vacant: 








PARA LINE POSN GR MOS BR JOB TITLE AUTH 
FAMILY PRACTICE CLINIC (FPC 

532 03 13 03 61H00 MC FAM PHYS Lo 
532 03 14 03 61H00 MC FAM PHYS NO 
52 12 02 03 00679 GS MED CLK (T) YES 


PARAGRAPH SUBTOTAL *** VACANCIES : 3——(1) 


EMERGENCY MEDICAL SERVICE (EMS) 
581 17 01 13 00602 GS GEN MED OFF YES 
581 17 02 13 00602 GS GEN MED OFF YES 





Figure 58. Vacancy Listing 
This report file is generated in the same manner as the position 
listing except that only the TDA positions which do not have Xem person 
assigned to a position are printed. 
The following numbered items correspond with Figure 58. 
] This is a count of all authorized positions that are vacant within a given TDA 


paragraph number. This total represents the sum of the authorized field for the 
TDA paragraph. 
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2 If the position is authorized (code=1), "YES" is displayed, otherwise "NO" is 
displayed. 


3 Total Department Vacancies. This total is the sum of all TDA paragraph 
subtotals mentioned in Note 1 above. 


(6) Social Roster (see Figure 59). This roster provides personnel 
within the department a roster of personal information of assigned personnel within the 
department. This roster both serves as a social listing to facilitate social gatherings and 
as an emergency notification listing for department personnel. The creation of this 
report requires the combination of the personnel database and personal database. In the 
case where there is not a match to a personnel record in the personnel database, "NO 
PERSONAL DATA" is printed in the report. 

The fields necessary to create this report are: 
* Last Name. 
e First Name and Middle Initial. 
e Rank. 
* Branch of Service. 
* Military Occupational Specialty Code. 
* Arrival Date within the Department. 
e TDA Official Job Title. 
e Section Description for each TDA Paragraph Number. 
e Local Home address. 
* City of Home address. 
e State. 


e Spouse's first name. 
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e Children's names, followed by their ages (if appropriate). 
e Home telephone number. 


e Date of rank. 


SOCIAL ROSTER 
DEPARTMENT OF FAMILY PRACTICE & COMMUNITY MEDICINE 


11 MAR 89 





PRIVACY ACT STATEMENT 


ee, tt rA, 





DEPARTMENT OF FAMILY PRACTICE (DEP) 


LTC SMITH, JOHN R. POSN: C, DEPT FP 
BR: MC MOS: 61H00 ARR: 07/20/87 


1200 BIRDTREE LANE 
ANYWHERE STATE 99999-9999 
PHONE: (408)999-9999 

WIFE: BECKY CHILDREN: JIM/10, MIKE/4, SUE/1 


FAMILY PRACTICE CLINIC (FPC) 


LTC JONES, SUE R. POSN: FAM PHYS 
BR: MC MOS: 61H00 ARR: 07/20/88 


1200 SINGASONG ROAD 

ANOTHERPLACE STATE 99999-9999 
PHONE: (408)888-8888 

WIFE: N/A CHILDREN: BECKY JOE/1 


MAJ BURB, HERB R. POSN: FAM PHYS 
BR: MC MOS: 61H00 ARR: 06/11/85 


23 CHIRPING TREE LANE 
ANYWHEREELSE STATE 99999-9999 


PHONE: (408)444-4444 
WIFE: JO CHILDREN: 


Figure 59. Social Roster 
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This report is created in the format shown in Figure 59. Entries 
are sorted by TDA paragraph number and then by rank within the position paragraph 
number. 

(7) Monthly Absence Report (see Figure 60). This report provides the 
department with a listing of personnel who have planned absences, either a planned 
CME course or a regular absences (i.e., leave), within an selected month. This report 
is used by the department managers and the clinical director (see scheduling 
information system) to manage personnel assets on a month to month basis. The user 
is required to enter the month and the fiscal year desired prior to output of this report. 
This report is generated by combining the absence database and the CME request 
database and then combining this new database with the personnel database to get the 
rank and name of the person who plans to be absent in the selected month. The report 


file is then sorted by section and last name prior to printing. 


MONTHLY ABSENCE REPORT 
DEPARTMENT OF FAMILY PRACTICE & COMMUNITY MEDICINE 
11 MAR 89 


MONTH : JULY «——(1>————+FISCAL YEAR : 89 
The following personnel have planned absences during the month of July: 





RANK NAME Q SECTION START_DATEEND DATE TYPE 
CPT JOHN SMITH AMB 07/01/89 07/15/89 CME 
CPT JANE DOE o CTM 06/01/89 07/02/89 EMER LV 
MSG GERY JONES | CTM 07/09/89 08/25/89 LEAVE 
ILT WAYNE SHARPE FPC 07/20/89 07/22/89 PERM TDY 
SGT WAYNE ROGERS POM 07/30/89 08/30/89 ORD TOY 


Figure 60. Monthly Absence Report. 
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The fields required to produce this report are: 
e Rank of the person who has an absence planned during the requested month. 
* Last Name. 
e First Name. 
« Section of assignment. 
e Start date of planned absence. 
* End Date of planned absence. 
* Type of Absence. 

The following numbered items correspond with Figure 60. 
1 The fiscal year and month desired are entered by the user prior to output of 
report. If the record in the combined database falls within the requested start date 
or end date, the absence record is included within the report. If the record 1s 
inclusive of the requested start and end date, e.g., a request in July falls between 
a user specified start date in June and an end date August, the record will be 


included in the report. 


2 Section codes are sorted to keep personnel along organizational lines. The 
secondary sort is on the last name. 


3 Type request code is converted to its full text format. Care must be taken not 
to assign the same type code to both the CME database and the absence database. 


4 The RANK, FIRST NAME, and LAST NAME fields are concatenated to give 
the appearance that the field is one field. 


(8) Fiscal Year Summary of Physician Absences (see Figure 61). This 


summary report provides the Department Chief with the ability to monitor and evaluate 
the number of and frequency of doctor absences within the department. This report 
serves aS an indicator of doctor availability over the fiscal year and shows the 
frequency of absences by type of request. This report is generated in the same manner 


as described in the absence report except this report is not restricted to one month and 
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extracts only doctor information. The user is only required to enter the fiscal year 
desired. The fields necessary to generate this report are the same as the absence report 


but also include the duration field from both of the databases. 


FISCAL YEAR ABSENCE SUMMARY 
DEPARTMENT OF FAMILY PRACTICE € 
COMMUNITY MEDICINE 
11 MAR 89 


FISCAL YEAR : 89 


NAME START DATE END DATE DURATION 
LTC JOHN SMUCK 
TYPE : CME REQUEST O 
01/01/89 01/30/89 29 
06/05/89 06/10/89 5 
Subtotal. eee eee 34 
TYPE : ORDINARY LEAVE (4) 
03/05/89 03/30/89 25 
06/10/89 06/20/89 10 
Subtotal. eenaa eaan e 3 
Total... det c 69 days 


LTC JANE SMITH 
TYPE : CME REQUEST 


03/01/89 03/30/89 29 
04/01/89 04/19/89 18 
05/05/89 05/15/89 10 
Subtotal............. mA 57 
TYPE : PERMISSIVE TDY 
09/25/89 09/30/89 5 
Subtotal A o 5 
TYPE : ORDINARY LEAVE 
02/01/89 02/28/89 27 
Subtotal... aee caste EE 27 5 
Total slan esses e EE EERETETE 89 days 


Figure 61. Fiscal Year Summary of Physician Absences. 
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The following numbered items correspond with Figure 61. 


1 Each person identified as having at least one absence during the fiscal year is 
reported in last name order. 


2 Under each person, all absences are sorted by request type in alphabetical order 
with breaks between different types of absences. 


3 Duration is extracted directly from the databases reflecting the End Date minus 
the Start Date in days. 


4 Subtotal of the duration for each type of absence, for each person. 
S Total duration for all absences for the given person. 
(9) CME Reports (Actual and Estimated) (see Figures 62 and 63). 
These reports allow the Department Chief to monitor the CME expenditures and 
estimate the funds remaining for a given fiscal year. The CME reports are critical in 
keeping track of the limited funds available to send doctors to the training necessary 
to keep them certified in critical medical skills. 
These two reports are very similar but are used in separate contexts. 
The Actual CME Budget Expenditure Report is used to report the amount actually 
spent during a given fiscal year, excluding all estimated costs figures. This report gives 
the Department Chief an accurate look at the funds remaining for the requested fiscal 
year. The Estimated CME Budget Expenditure report not only gives the Chief a look 
at what funds have actually been spent, but also provides a listing of the approved 
CME funded travel for which travel claims have not yet been settled. This report is 
also used at the beginning of the fiscal year to report the projected expenditures for 


a requested fiscal year. 
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CONTINUING MEDICAL EDUCATION 
ACTUAL FUNDS REPORT 








DEPARTMENT OF FAMILY PRACTICE & 








COMMUNITY MEDICINE (IDA) m 
11 DEC 89 

NAME RANK DATES OF TDY ^. LOCATION REASON TRAVEL PER REG REIMB TOTAL UNCOMMITTED 

OF TDY FOR TDY COST DIEM FEE COST COST FUNDS 

FUNDS ALLOCATED : 16789.92 

SMITH, JOHN CPT 09/09/89-09/20/89 LAS VEGAS, NV ORTHO 147.00 320.00 395.00 O0 862.00 15927.92 

JONES, JANE MAJ 10/10/89-11/20/89 RENO, NV AOA 169.25 437.50 210.00 50 866.75 15061.17 
D A9 
d e 

CME TRAVEL APPROVED BUT NOT COMPLETED (ESTIMATED COSTS) 12500.00 

PROJECTED FUNDS REMAINING 3561 18 





Figure 62. Actual CME Budget Expenditure Report 


CONTINUING MEDICAL EDUCATION 
ESTIMATED FUNDS RERORT 





DEPARTMENT OF FAMILY PRACTICE & 
COMMUNITY MEDICINE (IDA) 1 
ii DEC 89 

NAME RANK DATES OF TDY LOCATION REASON TRAVEL PER REG REIMB TOTAL UNCOMMITTED 
OF TDY FOR TDY cost DIEM FEE COST COST FUNDS 

FUNDS ALLOCATED 3 16789.92 

SMITH, JOHN CPT 01/05/89-01/20/89 LAS VEGAS, NV ORTHO 147.00 320.00 395.00 O0 862.00 15927.92 
JONES, JANE MAJ 05/10/89-05/20/89 RENO, NV AOA 169.25 437.50 210.00 50 866.75 15061.17 
ANDERS, KEN CPT 07/20/89-08/15/89 SAN DIEGO, CA EMERG 100.00 400.00 200.00 50 750.00 r4 3 ET 

ALL ESTIMATED AND ACTUAL TRAVEL COSTS REPORTED HERE O 
PROJECTED FUNDS REMAINING 14311.17 


Figure 63. Estimated CME Budget Expenditures Report 


The user is required to enter the fiscal year of the report prior to 
creation of either report. The fields required to create these reports are: 
e Last Name of requestor. 
e First Name. 
e Rank of the requestor. 
e Start and End dates of travel. 


e Destination. 
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* Purpose of Request, e.g., ORTHO WORKSHOP. 


e All Costs of travel, including the Travel Cost, Per diem costs, registration fee, 
reimbursable expenses, and total cost fields of the request. 


e Cost Code, whether it is an actual accrued cost or an estimated cost of the 
travel. 


e Allocated CME budget for the fiscal year from the CME allocation database. 
To create this report requires that the CME request database be 
combined with the personnel database to match the name of a person with the PIC in 
the CME request database. The CME allocation database is also used to determine the 
actual allocation for the selected fiscal year. 
The following numbered items correspond with the numbers in 
Figures 62 and 63. 
1 This number is the actual allocation for the current fiscal year selected. 


2 This is an accumulated total of the actual costs incurred for the current fiscal 
year. 


3 This number reflects the allocation for the current fiscal year minus the actual 
expenses already incurred. 


4 This figure is the previous allocation minus the total cost of travel for the 
current record. 


4. Scheduling Information System 
We concluded in Chapter IV that although automating the scheduling system 
would be impractical, improvements could be made in the system by standardizing the 
forms used in data collection and reporting. 
Figure 64 is the UCD depicting the proposed scheduling system. Although 


most of the scheduling process will remain the same, the clinical director will now be 
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able to get pre-printed standard forms for recording doctor availability information. 
These forms can be created with commercially available software packages (e.g., 


FORMTOOL) and maintained on diskettes in the administration office. 






Department 
Appointment 
System 
(COSTARS) 






Doctor Monthly 


Create 
Doctor 
Schedules 










Record 





Doctor 






Information 






Clinical Director 






Doctor 
Availability 
Information 


Doctor Information 


scheduling 


Folder 





Blank Forms 

















Print Form Update 
Schedule File Forms Changes Schedule 
Forms — — Forms 
Form Form Form 

Formats 


Selections Updates 


Forms File 


Figure 64. Scheduling User Concept Diagram 
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After discussions with the clinical director, it was determined that the most 
valuable forms to standardize are the duty history sheet, the monthly cumulative tally 
sheet, and the clinic schedule template. Other sources of information such as the 3x5 
cards containing staff doctor and resident’s special availability instructions were 
considered to be adequate in their current form. The resulting forms are shown in 
Figures 65 and 66. 

Figure 65 is the Duty History Record which is a combination of the duty 
history sheet and the monthly cumulative tally sheet. A completed duty history record 
will provide the scheduler with a comprehensive history of each doctor’s on call duty. 

Figure 66 is the clinic schedule template. Since this form is a template, 
the staff doctors permanent schedules are included. The template can be penciled in 
by the scheduler to show residents’ schedules for the month. The resident’s names can 
then be entered into the form using the fill-in-form option of FORMTOOL and a 
complete schedule can be printed for distribution. The clinical director liked the idea 
of the template. The template can be changed easily and each month a clean template 
can be used without having to first delete the resident’s names from the previous 


month’s schedule. 


Dole Duly History Record 
er KÉ Jan d » iy " dun Jul Aug 3 Oct Nov Dec Weekends [olds tags 


A AS AAA — o l 
py A M — Q— = 
A PPP A a a "— 


Figure 65. Duty History Record 
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Month YE Schedule Template —— — 


TEAMS MONDAY TUESDAY WEDNESDAY THURSLAY FRILAY 


Gold A Foster 
M 
Lorenzen 
Mork 
Foster 
Birdsong 
Landauer 
Crisp 
Spinelli 
Herman P|Mork Lorenzen Foster Mork Mork 
L EA E- 
Red 


Forred Forred Fuller Forred 
Fuller 
Forred 
Hutnak 
Lee 
Schmidt 
Walcott 
Bradley 
Sorensen 
Fuller Forred Forred Fuller 
Fuller 








Lorenzen 
Foster 





Ao 


a Y 


Blue Spaulding Spaulding Kugler Spaulding Spaulding 
Kugler Yeash Yeash Piit Hanns Kugler 
Yeash 


Kugler 
Spaulding 
Yeash 

Ard 
Runkle 
Davis 
Goodrich 
Swann 
Terrio,J P|Yeash Fitzharris Spaulding Kugler Yeash 
Weaver M Kugler 





Figure 66. Schedule Template 
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5. Patient Satisfaction Information System (see Program, Appendix F) 
a. Data Structures 
As can be seen in the UCD in Figure 67, the entire patient satisfaction 
system hinges on completed patient surveys, the results of which are entered into a 


survey database for use in report generation. 


Blank Survey Complete 


A cu 





Survey Completed Survey 





Doctor Potient 















Reception 
Desk 
Box 
Report 
Dota Survey Survey 
2.0 Print Dotobose Dala 
Reports 
New Survey 
| Data 
QA Rep, Clerk 1.0 Enter New 
Reports Survey 
Dota 
Clinic Dept. 
Reports Reports input Date 





QA Rep, Clerk 


Chief 


Figure 67. Patient Satisfaction User Concept Diagram 


The approved opinion survey, designed in cooperation with the 


Department Chief and the Quality Assurance (QA) representative, is shown in Figure 
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68. The questions and answers cover those areas of most concern to the Department 


Chief. The survey form determines the data structure of the database itself, with data 


fields corresponding to each question. The following data fields are used in the 


database to record survey data. 


Month. The month the survey was completed by the patient. 
Year. Calendar year the survey was taken. 
Section Code. Same as systems above. 


Doctor’s Name. The name of the doctor seen by the patient completing the 
survey. 


Appointment Days. Question 1A. 

Appointment Acceptability. Question 1B. 

Records Ready. Question 2. 

Waiting Time. Question 3A. 

Waiting Acceptability. Question 3B. 

Receptionist Courtesy. Question 4. 

Nursing Courtesy. Question 5. 

Doctor Courtesy. Question 6 

Procedures Explanations. Question 7. 

Time Spent With Doctor. Question 8. 

Clinic Cleanliness. Question 9. 

Overall Satisfaction. Question 10. 

Patient Comments to Enter?. The user entering the survey results into the 
survey database must enter a "Y" in this field to indicate there are comments 


to be added to the database for this survey. An "N" indicates there are no 
comments. The following section on Inputs explains this further. 
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e Comments. A memo field which the user can fill from comments made on the 
patient survevs. 


Department of Family Practice 
Fatient Cpinion Survey 


Your opinion is important to us. Please complete this survey and return it 
to the box located at the reception desk. 
Sincerely, 
Chief, Department of Family Practice 
Month Year cime Doctor 
PLEASE CIRCLE THE ANSWER TO THE RIGHT OF EACH QUESTION 
l.A.How many days did it 1) Same 2) Less 3) Less 4) Less 5) More 


take to get your Day than 7 than 14 than 30 than 30 
appointment? 


B.Was this time 
acceptable? 1) Acceptable 2) Not Acceptable 


2.Were your records ready 
at the front desk? IDEES 2) NO 


3.A.How long did you wait |1) Less 2) Less 3) Less 4) Less 5) More 
to see the doctor? than than than than than 
15 mim 30 min 45 min l1 hour l1 hour 


B.Was the waiting time 
acceptable? 1) Acceptable 2) Not Acceptable 


PLEASE CIRCLE THE NUMBER TO THE RIGHT OF EACH QUESTION WHICH MOST CLOSELY 
MATCHES YOUR OPINION BASED ON THE FOLLOWING SCALE: 


S=Excellent 4=Good 3=0F. 2=Needs Improvement l-Unsatisfactory 





EN curtesv ofb?receptionists..... 5 i sies sr rase s sn s 4 22d. 32.2 1 
IESU rtesy ofonursing Staff.......o.ooonoonoa.oo.osos.». 5 4 3 2 1 
NS e cf doctor sce ees Tis CON OU EM OUS TN de id 
7. Explanation of procedures (lab work, EKG's, etc)..... 220. 3 2 1 
8. The amount of time the doctor spent with you......... cq 3 2 —I 
9. The general cleanliness of the clinic............ pgs 2 1 
10. Overall satisfaction with the care you received...... 3$. d 3-2. I 


COMMENTS: 





THANK YOU !! 


Figure 68. Opinion Survey Form 
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b. Data Inputs 

The Patient Opinion menu hierarchy chart is depicted in Figure 69. 
The user can enter new survey data using the input screen shown in Figure 70. This 
input screen contains all of the data base fields arranged in a format similar to the 
actual survey for simplified data entry. The answers to the survey's numbered 
questions are coded: the user simply enters one number corresponding to the survey 
answer. Since each question has a predetermined number of responses, error checking 
is simply a matter of verifying the input number falls in the allowable range. For 
example, question 1A has five possible answers. If the user entered anything other 
than one through five, a bell would sound and a message saying the input was out of 
range would appear at the bottom of the screen. The user is then given the chance to 
enter the correct answer. At the bottom of the input screen the user is asked if there 
are comments to be entered. The user enters a "Y" or "N" in the Patient Comments 
to Enter field. The Patient Comments to Enter field is necessary when printing the 
patient comments report discussed in Outputs below because a memo field in the 
database program cannot be used to determine records to print. Therefore, it is 
necessary to have a second field whose value indicates whether the comment field is 
filled to allow only those records with comments to be printed. 

The use of mark-sense forms would allow automatic entry of the survey 
data into the database. Unfortunately, neither the department nor the hospital has the 
computer hardware to read mark-sense forms and there are no plans to acquire such 
technology. Additionally, we feel the added complexity of mark-sense forms, e.g., 


special marking requirements and additional instructions, would deter some patients 
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from completing the surveys. Also, the requirement to purchase specially designed 
forms may deter the department from obtaining the surveys. 


PATIENT OPINION SYSTEM 


MAIN 
MENU 


PRINT 
OPINION RESULTS 


ENTER 
NEW SURVEY DATA 





ACCESS WAITING SATISFACTION DOCTOR PATENT 
TO CARE REPORTS TIME REPORTS REPORTS REPORT COMMENTS 





DEPARTMENT DEPARTN ENT DEPARTMENT 
REPORT REPORT REPORT 
CLINIC CLINIC CLINIC 
REPORT REPORT REPORT 


Figure 69. Patient Satisfaction Menu Hierarchy Chart 
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Figure 70. Patient Satisfaction Input Screen 
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Once the survey data is entered into the database, the user can print 
one of several reports. After selecting the report desired from the menu, the user is 
prompted to enter information which further identifies the report parameters such as 
year, month, and (if necessary) the clinic’s section code. This information is used to 
gather the data necessary to create the desired output. 

c. Outputs 

(1) Access to Care Reports (see Figure 71). There are two access to 
care reports, one for the department as a whole, and one for each clinic. Both consist 
of two parts and are identical in content and appearance. However, for clinic reports, 
only the survey data for the selected clinic is used. Part One of the report, 
Acceptability of Appointment Access indicates to the Department Chief the patients’ 
opinions on the acceptability of the length of time it took them to obtain an 
appointment. Part Two, Average Days to Get Appointment, allows the Department 
Chief to examine the trend in the average number of days to get an appointment. 

The following fields are necessary for creating the two part access 
to care reports. 
* Month. 
* Year. 
e Section Code. For clinic report only. 
* Appointment Days. 


e Appointment Acceptability. Required only for Part 1, Acceptability of 
Appointment Access. 
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Acceptability of Appointment Access 
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T Days to Get Appointment 
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—— Average Days 


Figure 71. Access to Care Report 
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The following numbered items correspond to the numbers shown 
in Figure 71 and explain the data manipulations and calculations required to produce 
the report. 


1 The total number of responses for each possible answer to survey question 1A 
are graphed along the Y-axis based on note 2 below. 


2 For each possible answer to question IA, the number of patients who 
responded to question 1B as acceptable and unacceptable are counted and each 
count is graphed as a separate bar. For example, in the figure, for those patients 
that said it took them less than seven days to get an appointment, 15 said this 
was acceptable and one said this was unacceptable. 


3 The total response line shows the total responses for each possible answer to 
question 1A, appointment days. 


4 This is the month and year of the survey. This data is input by the user when 
requesting the report and is used by the program to select the appropriate survey 
database records. 


5 In Part Two, the days to get an appointment are graphed on the Y-axis. 


6 The responses to question 1A are averaged for each month of the desired year 
and plotted along the X-axis. 


(2) Waiting Time Reports (see Figure 72). As with the access to care 
reports, there are two waiting time reports, one for the department as a whole, and one 
for each clinic. The format of the waiting time report is similar to the access to care 
report for both department and clinic. Part One of the report, Acceptability of Waiting 
Time indicates to the Department Chief the patients' opinions of the acceptability of 
the length of time it took them to be seen by the doctor. Part Two, Average Waiting 
Time, denotes the trend over the calendar year of the average waiting time to see a 


doctor. 
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Figure 72. Waiting Time Reports 
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The following fields are necessary for creating the two part waiting 
time reports. 
e Month. 
e Year. 
e Section Code. For clinic report only. 
e Waiting Time. 


e Waiting Acceptability. Required only for Part One, Acceptability of Waiting 
Time. 


The following numbered items correspond to the numbers shown 
in Figure 72 and explain the data manipulations and calculations required to produce 
the report. 


1 The total number of responses for each possible answer to survey question 3A 
are graphed along the Y-axis based on note 2 below. 


2 For each possible answer to question 3A, the number of patients who 
responded to question 3B as acceptable and unacceptable are counted and each 
count is graphed as a separate bar. For example, in the figure, for those patients 
that said it took them less than 30 minutes to see a doctor, 17 said this was 
acceptable and three said this was unacceptable. 


3 The total response line shows the total responses for each possible answer to 
question 3A, waiting time. 


4 This is the month and year of the survey. This data is input by the user when 
requesting the report and is used by the program to select the appropriate survey 
database records. 


5 In Part Two, the waiting time is graphed on the Y-axis. 


6 The responses to question 3A are averaged for each month of the desired year 
and plotted along the X-axis. 


(3) Satisfaction Indicators (see Figure 73). Questions four through ten 


of the survey are statements for which the patient is asked to indicate his level or 
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degree of satisfaction ranging from five for excellent to one for unsatisfactory. The 
Satisfaction Indicator report shows the results of the survey in these seven areas, with 
the total number of responses for each level of satisfaction (one through five) graphed 


for each of the seven areas. 


Satisfaction Indicators 
July_1989 


Number of Responses 


30 
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Figure 73. Satisfaction Indicators 
The following fields are necessary for creating this report: 
e Month. 
e Year. 
e Section Code. For clinic report only. 


e Receptionist Courtesy. 
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e Nursing Courtesy. 

* Doctor Courtesy. 

* Procedure Explanations. 

e Time Spent With Doctor. 

e Clinic Cleanliness. 

e Overall Satisfaction. 

The following numbered items correspond to the numbers in Figure 

73 and explain the data manipulations required to produce the graph. 

1 The Month and Year for the report. 


2 The total number of responses in each level of satisfaction are graphed along 
the Y-axis. 


3 For each satisfaction indicator (e.g., doctor courtesy, overall satisfaction) the 
number of responses in each level of satisfaction (note 4 in the figure) are 
counted and the total for each level is graphed as a separate bar for all of the 
indicators along the X-axis. 

(4) Average Satisfaction Levels (see Figure 74). This two part report 
shows the average level of satisfaction for each satisfaction indicator for the calendar 
year. It is presented in two reports to simplify viewing. The Department Chief prefers 
line graphs to enhance trend identification so the seven indicators are divided into two 
groups. Part One shows the indicators which are primarily personnel oriented (e.g., 
courtesy) plus overall satisfaction. Part Two shows the remaining indicator’s averages. 

The following fields are necessary to create the two part report: 
* Month. 


e Year. 


e Section Code. For clinic report only. 
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e Receptionist Courtesy. For Part One only. 

e Nursing Courtesy. For Part One only. 

* Doctor Courtesy. For Part One only. 

* Overall Satisfaction. For Part One only. 

* Procedure Explanations. For Part Two only. 

e Time Spent With Doctor. For Part Two only. 

e Clinic Cleanliness. For Part Two only. 

The following numbered items correspond to the numbers in Figure 

74 and explain the data manipulations required to produce this report. 

1 This is the requested year of the survey data for the report. 

2 The average of all of the values (ranging from one to five) for each indicator 

is calculated for each month of the specified year. The satisfaction indicators are 

plotted along the X-axis using different line styles for each indicators average 


values. 


3 The average response for each indicator is correlated to it’s equivalent narrative 
description, i.e., | = unsatisfactory, and these are shown along the Y-axis. 


(5) Doctor Satisfaction Report (see Figure 75). This report is a table 
showing the average responses for a given month for four of the satisfaction indicators 
which most directly relate to the patient’s interactions with the doctors. This report 
is produced for all of the doctors in the department and allows the Department Chief 


to track individual doctor’s survey results. 
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Figure 74. Average Satisfaction Levels Report 
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DOCTOR SATISFACTION REPORT 


July_1989 

(2) O (4) 
DOCTOR COURTESY EXPLANATIONS TIME SPENT GENERAL OVERALL 

SATISFACTION AVG 

Baker 3.5 3.0 4.0 4.0 3.6 

Foster 4.0 qu? 3.6 4.0 4.0 

Kugler 44D 2.8 3.4 22 E SCH 

Lorenzen 4.5 4.0 4.7 4.5 — 404 

Mork 4.0 4.0 39399 4.0 279 

Yeash 3.0 4.3 2.8 4.0 3.) 


(9) 


Figure 75. Doctor Satisfaction Report 
The following fields are necessary for creating this report: 
* Year. 
e Month. 
* Doctor Name. 
* Doctor Courtesy. 
* Procedure Explanations. 
* Time Spent With Doctor. 
* Overall Satisfaction. 
The numbered items below correspond to Figure 75 and explain 


how the data for the report is obtained. 


p= 


This is the month and year for the report. 


N 


Each doctor’s name is printed in the first column in alphabetical order. 


|) 


For each doctor, the average response for the four indicators is calculated and 
placed in the corresponding column adjacent to the doctors name. 


4 The value of all four indicators is averaged to produce an overall doctor 
satisfaction average. 


5 An additional indicator of a physician's consistency could be computer here, 
e.g., standard deviation or some similar measure of dispersion. 


177 


(6) Patient Comments (see Figure 76). This report is a print out of 
all of the patient comments entered into the survey database for the desired month and 
year. It allows the Department Chief to review any constructive criticisms or 
noteworthy suggestions made by the patients and pinpoint other trouble areas (or 


outstanding areas) which cannot be identified from the quantitative portion of the 


survey. 
The fields necessary to produce this report are listed below: 
e Month. 
e Year. 
e Patient Comments to Enter? 
e Comments. 
The numbered items below, corresponding to Figure 76, explain 
the comment report. 
1 The month and year of the report is listed at the top. 


2 The records in the database which have the Comments field filled (indicated 
by a "Y" in the Patient Comments to Enter field) are printed in record number 
order for the month and year. 


PATIENT COMMENTS 
1 July 1989 


I THINK THE LAB AND PHARMACY TAKE TOO LONG, I WAITED FOR MORE THAN AN HOUR 
TO GET MY PRESCRIPTION FILLED. 


THE FAMILY PRACTICE CLINIC IS GREAT HERE. I WOULD LIKE TO BE ABLE TO SEE 
MY ASSIGNED DOCTOR MORE OFTEN, DR. YEASH, BUT WHOEVER SEES ME IS ALWAYS 
VERY COURTEOUS AND HELPFUL. 


I NEVER GET TO SEE THE DOCTOR WHICH MY FAMILY IS ASSIGNED TO, WHY BOTHER 
GOING THROUGH THE HASSLE OF SIGNING UP FOR A SPECIFIC DOCTOR? 


ITS TOO COLD IN THE EXAMINING ROOMS. 


Figure 76. Patient Comments Report 
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6. Productivity Information System (see Program, Appendix G) 
a. Data Structures 
The productivity system UCD is shown in Figure 77. The functions 
of the productivity system depend on visit information obtained from the Patient 
Administration Division for Gg section of the department. The method of obtaining 


the visit information is described in the next section, Inputs. 
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Figure 77. Productivity System User Concept Diagram 
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The visit information is entered into the visit database which consists 


of the following fields: 

e Fiscal Year. The fiscal year is used so the number of visits in each section can 
be directly compared to the section’s expenditures for each month. 
Expenditure data is maintained in the budget database by fiscal year. 

e Month. 


e Section Code. 


e Number of Visits. The number of patient visits for each section within the 
department as reported by the Patient Administration Division. 


b. Data Inputs 

The productivity system menu hierarchy chart is shown in Figure 78. 
Visit data for the entire hospital is collected monthly by the Patient Administration 
Division (PAD) for RMD. PAD enters each section’s visit information into a 
spreadsheet program which they use to create the MED 302 report, discussed in 
Chapters III and [V. For the department productivity system, the visit information can 
be extracted from the PAD MED 302 file for entry into the visit database. Table VI 
shows the locations of visit data in the MED 302 spreadsheet file corresponding to 
each section in the DFPCM. As can be seen in the Table VI, some calculations on 
the data in the file are necessary to accurately correlate the visit data to the DFPCM 
sections. For example, the CTMC section visit count is a combination of multiple 
lines and columns from the MED 302 file. The disparity occurs because PAD divides 
section visits into subdivisions for their hospital reporting requirements. For the 
Department Chief’s purposes, only the total visit information for each section is 


necessary. 
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Table VI. MED 302 DATA EXTRACTION LOCATIONS 


SECTION CODE LOCATION IN MED 302 (LINE #’s & COL’s) 


FPC SUM (134 A & B TO 140 A & B) 
CFP SUM (134C TO 140C) 

EMS SUM (147 A & B) 

FSO SUM (148 A & B) 

GOC SUM (141 A & B) 

POM 141D 

CTM SUM (141C, 171C, 174C, 141F) 
FHL SUM (141E, 171E, 174E) 
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WSIT FILE REPORTS & WSIT REPORTS 
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VISIT DATA WST DATA MONTH WSTS & CEPT VST EXPENDITURE. PCR EXPENDITURE VS 
FROM MEDSO2 FILE TRENOS WST REPORT WSIT TRENO REPORT 
ADO 


VET DATA 


CHANCE 
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REMOVE 
VISIT DATA 


REVEN 
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Figure 78. Productivity Menu Hierarchy Chart 


The visit information in the MED 302 file can be extracted for entry 


into the visit database in one of two general ways, either automatically or manually. 


181 


To extract the visit data automatically, an extraction program can be 
written to take data from the MED 302 spreadsheet file and load it on a floppy disk. 
Another program is necessary to transfer the data from the disk into the department 
productivity system’s visit database in the correct format. 

Manual extraction would require PAD to print the department’s sections 
and visit data, monthly, to a paper report. The user of the department productivity 
system would select the "Add Visit Data” option from the "Update Visit Data” menu 
and enter the visit data contained in the printed report provided by PAD. The input 


screen for adding, changing, or removing visit data is shown in Figure 79. 


Fiscal Year Section Code # of Visits 


Section Codes 


Family Practice Clinic FPC Consolidated Troop Clinic CIM 
General Outpatient Clinic GOC Fort Hunter Liggett 

CTMC Family Practice CFP Ambulance Section AMB 
Emergency Medical Service EMS Flight Surgeon Office 

Presidio of Monterey POM 





Figure 79. Visit Data Input Screen 

Either of the above input methods is technically feasible. However, 
there are tradeoffs in choosing one method over the other. The automated method 
eliminates the need for manual entry of each section’s visit data every month. On the 
other hand, the amount of data entry is relatively small. There are eight sections with 
visit data requiring approximately 11 keystrokes for each section (see Figure 79). 
Thus, in any given month, it would require approximately 90 keystrokes to enter the 


new visit information into the database. The main drawback to automating the 
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information extraction lies in the MED 302 file itself. PAD created the spreadsheet 
file for their own use in creating the hospital’s MED 302 report. The DFPCM has no 
control over PAD’s use of the spreadsheet file. Therefore, any changes PAD might 
make to the file would cause any extraction program referencing specific lines and 
columns to fail. Other changes in the method of visit data collection or reporting 
would likely require changes in the extraction programs. Both extraction methods 
require cooperation and coordination between the DFPCM and the PAD, with the 
automated method requiring considerably greater effort. 

The method of extraction aside, once the data is contained in the 
database, the user can view the data by selecting one of the outputs described in the 
following section. 

c. Outputs 

(1) Review Visit Data. The review is an option under the "Update 
Visit Data" menu and allows the user to view the entire visit database. All of the 
database fields are displayed in the standard review format described in Section C.2.b., 
Review Screens. 

(2) Department Monthly Visit Report (see Figure 80). The monthly 
visit report is a bar graph showing each sections” total visits for the desired fiscal year 
and month. This report provides the Department Chief with a quick indication of the 
level of work done by each of the eight sections reporting visit information. All of 


the visit database fields are necessary to create the monthly visit report. 
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The following numbered items correspond to the numbers in Figure 


80 and explain the monthly visit report: 
1 The month and year for the report. 
2 The total number of visits (in thousands) for each clinic is plotted on the Y- 
axis. 
3 The eight department sections are plotted along the X-axis. 


DEPARTMENT MONTHLY VISITS 
Joly 1989 


Number of Visits (thousands) 











EPC EMS GOC CFP FHL FSO POM 
Department of Family Practice Sections 


Figure 80. Department Monthly Visit Report 
(3) Visit Trend Report (see Figure 81). The visit trend report is a 
multiple graph report showing fiscal year trends in patient visits for each section. To 


simplify viewing, only two sections are shown on each graph resulting in four graphs 
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Figure 81. Visit Trend Report 
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for the entire report. All of the visit database fields are required for the visit trend 
report. 
The following numbered items correspond to the numbers in Figure 
81 and explain the visit trend report. 
1 The fiscal year of the report. 


2 The number of visits for each clinic is plotted in the appropriate graph on the 
Y -axis. 


3 Each month of the reported fiscal year is graphed along the X-axis. There are 
two sections plotted on each graph, each with a different trend line style. 


(4) Expenditure/Visit Comparison Report (see Figure 82). The 
expenditure/visit comparison report shows the dollar amount spent per patient visit. To 
obtain the data necessary to produce this report, the information in the visit database 
must be combined with information from two of the databases maintained by the 
budget system: the APC monthly expenditure database; and the APC database. 
Because of the relationship between the APC and the Section Code, the visit database 
must first be combined with the APC database to relate the visit database section code 
with the APCs used in the budget system. The resulting combination must further be 
combined with the APC monthly expenditure database. This combination is necessary 
to relate the number of visits for a particular section code to that section’s expenditures 
for the same month and fiscal year desired for the report. The three databases and 


their field relationships are shown in Figure 83. 
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Expenditure/Visit Comparison 
July 1989 


E $ Expended Per Visit 





CPF 
Sections 


Figure 82. Expenditure/Visit Comparison 
The combined data fields necessary to create the report are listed 

below: 

e Fiscal Year. 

e Month. 

e Section Code. 

e APC. 

* Expenditure. 


e Number of Visits. 
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The following numbered items correspond to the numbers in Figure 
82 explaining the comparison report. 
1 The month and fiscal year of the report. 
2 The dollar expenditure per patient visit is plotted along the Y-axis. For each 
section, divide the monthly expenditure by the monthly number of visits to arrive 


at the expenditure per visit amount. 


3 Each section is plotted along the X-axis with a vertical bar showing the dollar 
expenditure per visit. 


VISIT DATABASE 
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MONTHLY EXPENDITURE DATABASE 










APC DATABASE 


Figure 83. Productivity and Budget Database Relationships 

(5) Department Expenditure and Visit Trend Report (see Figure 84). 
The expenditure and visit trend report allows the Department Chief to rapidly assess 
the general direction department spending is taking in comparison to the department’s 
workload. The process for obtaining the information for the report is similar to that 
used in the Expenditure/Visit Comparison report discussed previously. The same 
combined database fields are used in both reports, however, the calculations for each 


report are different. 
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The following numbered items correspond to the numbers in Figure 

84 and explain the data calculations required to produce the expenditure and visit trend 
report. 

1 The fiscal year of the report. 

2 The dollar amount of department expenditures for each month of the fiscal 

year. Sum the eight section's expenditure data for each month to obtain the total 

monthly department expenditures. 

3 The number of department visits for each month of the fiscal year. Sum the 

eight sections’ visit data for each month to obtain the total monthly department 

Visits. 

4 The dollar amount of expenditures and the number of visits are both plotted 


on the Y-axis. The numbers along the Y-axis represent both thousands of dollars 
and thousands of visits. 
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Figure 84. Department Expenditure and Visit Trend Report 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. PROJECT SYNOPSIS 

We began our information systems development project for Silas B. Hays by 
studying the current literature on information systems development and hospital 
information systems. The findings of this literature research were presented in Chapter 
II. In summary, there were a multitude of systems development methodologies from 
which to choose. We determined that a combination of two commonly used 
methodologies, a traditional systems development life cycle and a prototyping 
methodology, would best fit our needs. The life cycle methodology provided us with 
the structured techniques to develop the proposed information system, while prototyping 
allowed us to quickly develop the user interfaces necessary to rapidly identify user 
requirements. Through research, we determined that the critical nature of the health 
care environment influences the information systems used by hospitals. There exists 
a dichotomy between the goals and objectives of hospital administrators and health care 
providers. This dichotomy influences the way in which information systems are used 
to meet these differing objectives. Additionally, the resource constraints within the 
hospital create pressures when considering the use of information systems by both 
administrators and health care providers. This was particularly true in the case of the 
DFPCM, whose Chief is both a health care provider, and by necessity, an administrator. 

We conducted interviews with senior hospital managers to obtain a clear problem 


definition and to focus our research. The feedback from these discussions directed us 
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to the Department of Family Practice and Community Medicine (DFPCM). This large, 
multi-service department greatly affects overall hospital operations. Chapter IM 
provided a detailed look at the DFPCM: its structure and its current information 
systems. The Chief of the DFPCM commands more than 150 people and manages an 
annual budget of nearly half a million dollars. In initial discussions with the Chief, 
he identified and prioritized his most critical management concerns: budget, equipment, 
personnel, scheduling, patient satisfaction, and productivity. The information systems 
relating to these six management areas became the subject of our research. 

Discussions with the Department Chief and his senior department personnel 
helped us identify their requirements for information in each of the six areas. In 
analyzing their needs, and comparing the needs with the current information systems, 
we were able to propose improvements to the systems in Chapter IV. Those 
improvements included: the use of databases; simpler data collection; automated data 
manipulations (in some cases); concise, summary reports; graphical reports; trend 
analysis capabilities; and improved automated user interfaces (where applicable). 

The improvements proposed in Chapter IV were prototyped in Chapter V to 
produce a detailed requirements analysis for the six information systems in the DFPCM. 
The databases, user interface screens, and outputs of the systems were designed to help 
us pinpoint the user’s requirements. The Department Chief and other department 
managers provided feedback, allowing us to tailor the prototyped models to their 
specifications. Time constraints allowed only one iteration of the prototyping process. 


Further iterations would further enhance the requirements analysis presented in Chapter 


V. 
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The general conclusions resulting from our research are presented in the following 
section. The recommendations for follow on thesis study are discussed in the last 


section of this chapter. 


B. CONCLUSIONS 

The requirements analysis presented in this thesis is the first step in the 
development life cycle for the DFPCM information system. With the existing 
information system defined and the requirements identified and analyzed, the system 
can be fully designed, constructed, and implemented to meet the needs of the targeted 
department users. 

The process of requirements analysis is a complex task which if done poorly will 
likely result in a substandard system development. The complexity of this task leads 
to many difficulties which the analysts must face during the development process. 

Identifying the system's target audience and obtaining a clear problem definition 
are essential first steps in the process. Without a clear understanding of the intended 
users and their related problems, the analyst's energies and resources are wasted on 
unimportant or non-existent requirements. Starting on the right track early in the 
process requires the involvement of senior management to obtain the input from those 
personnel who are in a position to identify problem areas. Once involved in the thesis 
study, the senior managers at Silas B. Hays were quick to identify the DFPCM as 
potential benefitors of an improved information system. Frequent and early interactions 
with the users were critical in identifying the detailed requirements of each of the 


subsystems presented. 
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Selecting the "best" development methodology is the next hurdle in the 
development process. Given the large number of methodologies in existence, it is 
doubtful there is one "best" method. Rather, the analyst must choose the methodology 
most suited to the task at hand, with which he has the most experience, or simply, one 
which he feels most comfortable using. Decisions such as whether to use data flow 
diagrams or user concept diagrams depends on a number of factors, the bottom line 
being whether or not the analyst can use the method effectively to build a high quality 
system acceptable to the intended users. 

The use of prototyping in the early stages of system's development was shown 
to be beneficial in identifying the inputs, interfaces, and output requirements desired 
by the intended users. Using separate software packages to design the various 
prototypes was time consuming and did not allow direct integration of the input and 
output prototype programs. The use of a dedicated, integrated prototype tool which 
does all of these processes could have greatly enhanced our productivity in prototype 
development. 

The project management of the system development is critical for an efficient and 
effective process. The division of labor, coordination of effort, and teamwork were 
important issues throughout the project. When these factors are missing or inadequate 
in project development, schedules slip and resources are wasted. 

An important influence in the development project at Silas B. Hays is the 
complexity of the computer systems in place at the hospital. The lack of integration 
of these systems frustrates the development of an information system and ultimately 


causes more work for the users in duplicating the data collection and reporting efforts. 
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The integrated Composite Health Care System planned for implementation in the early 
1990s does not answer the needs of the department managers today. The new Director 
of Information Management at Silas B. Hays has begun planning for solving the 
integration problems using networking technology. 

A valuable lesson learned during the writing of this thesis was that the use of 
automation is not always appropriate in every part of an information system. In some 
cases, automation would actually create more work in relation to any benefits gained. 
With the intense workload of the department’s personnel, every effort must be made 
to reduce the amount of work required while providing the best possible information 


to the department chief. 


C. RECOMMENDATIONS AND FOLLOW-ON THESIS WORK 

The requirements analysis presented in this thesis should be used to further design 
and implement a complete information system for the DFPCM. The hospital’s 
Information Management Division can use the prototype program listings, and input and 
output examples to develop a working system using the software packages currently 
available in the hospital, or they can use the requirements to justify purchasing or 
developing other software as required to implement the systems. Possible follow on 
thesis work in this area includes designing, constructing, and/or implementing an 
information system from a previously developed requirements analysis. Evaluating and 
selecting software and hardware altematives, including thorough economic analyses, 
provide additional possibilities for future research. 

The information which could be provided to hospital managers by a completed 


system may be useful to other hospital departments. Follow on thesis work could 
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involve expanding the initial requirements analysis of this thesis to other departments 
or the hospital as a whole. 

Additional follow-on thesis work include: research into the design of an 
optimization model for the doctor scheduling process and further research into the 
doctor productivity issues discussed in Chapter IV. 

At a minimum, the analysis contained in this thesis can be used by senior 
hospital managers to identify the shortcomings of the existing information systems in 
providing department managers with the high quality information they require to 


successfully manage the many resources needed to accomplish their missions. 
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APPENDIX A. DATA DICTIONARY 


BUDGET DATABASE FILES 


APC FILE 


FIELD FIELD FIELD DESCRIPTION 
NAME TYPE LENGTH/ OF FIELD 
DECIMALS 


Seeron  |cmaracrer | 20 | o [NAME OF SECTION ASSIGNED TO APC CODE | 

srercooe_ |emracrer | 3 | o |seorron coos o o 

poc [emaracrer | 1s | o |romr or conraer 00000000 

meuernone |wowerrc | o | o [rerepnone NUMBER : FORMAT (999) 999-9999 

sratus |CHARACTER | 1 | O0 | STATUS CODE [ A: ACTIVE, I:INACTIVE ] 
LENGTH/ 


OTRALLOCG FILE 
FIELD FIELD 
NAME TYPE 
DECIMALS 

arc [CHARACTER me ee ACCOUNT PROCESSING CODE 
FY ^ [numeric B FISCAL YEAR OF ALLOCATION 

QUARTER NUMERIC |a [o | QUARTER WITHIN THE FISCAL YEAR 
ALLOCATION |MONEY BUDGET ALLOCATION FOR THE QUARTER 


MOEXP FILE 
FIELD FIELD 
NAME TYPE 


QUARTER NUMERIC EL 
expenses [money [11 | 2 




























DESCRIPTION 
OF FIELD 


FIELD 




























DESCRIPTION 
OF SETELD 


1:9 


FIELD 
LENGTH/ 
DECIMALS 












nj 
lii 
; 
D 
H 
Q 
Te 


EQUIPMENT DATABASE FILES 


EQUIP FILE 


FIELD DESCRIPTION 
NAME TYPE LENGTH / OF FIELD 
DECIMALS 
secrcope _|cuaracrer | 3 | 0 |secrzon cope o 
regoare [pare | e |o [pave or onscrwaL Requesn | 
pesceser [cmaracrer | 20 | o |DeSCRIPTIVE NAME OF EQUIPMENT NEEDED —- 
Reoryee  Jemaracrer | 4 |o | TYPE OF EQUIPMENT REQUEST, i.e. CEEP 
prxorzty _|womersc__| 2 | 0 |erromrry Or REQUEST WITHIN TYPE OF EQUIP 
ore |momemre | s |o |ouawrrry or roureMewT NEBDED — 
la | 2 [price pen UNIT or EQUIPMENT REQUESTED | 
2 | o [sratus or reouest IN CODED FORM | 
[20 |o [coments on reouest 


EOHTSTOETHE 


FIELD FIELD FIELD DESCRIPTION 
NAME TYPE LENGTH/ OF FIELD 
DECIMALS 
Y 


UNITPRICE MONEY 
EXTPRICE MONEY 


rrscaces — Jomaacres | 20_| 6 Joer AN 
“= | 
a 2 
Sen SE 
eos ie NM 
o Ja NM 

TT 


COMMENTS 


DATE OF ORIGINAL REQUEST 
DATE TRANSFERRED TO HISTORICAL FILE 
MONTHS IT TOOK TO COMPLETE REQUEST 


COMMENTS ON REQUEST 





TOS 


PERSONNEL DATABASE FILES 


PERSONNEL FILE 


FIELD FIELD FIELD DESCRIPTION 

NAME TYPE LENGTH/ OF FIELD 
DECIMALS 

IDCODE CHARACTER 5 PERSONNEL IDENTIFICATION CODE 


20 
is 


LAST NAME 


FIRST NAME, MIDDLE INITIAL 


PERSONAL FILE 


FIELD FIELD FIELD DESCRIPTION 
NAME TYPE LENGTH/ OF FIELD 
DECIMALS 
ADDRESS CHARACTER PERSON'S ADDRESS (HOME) 
CITY CHARACTER CITY (HOME) 
STATE CHARACTER STATE (HOME) 
ZIPCODE N RIC 


o 
zo [o 
[2 jo 
a fo 
[9 |o [meos £a wow) o 
as [o 
ls o 
pe fo | 
so fo | 


5 
a 
3 
CHARACTER | 3 


Z 





z. 
0 
k 
Fu 
O 
n 
a 
ps 
H 
Q 





















WIFE’S NAME 
CHARACTER 
ER ec 


CHILDREN'S FIRST NAMES AND AGES 


TELEPHONE NUMBER WITH AREA CODE (HOME) 
DATE OF RANK 
COMMENTS (PERSONAL) 
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TDA FILE 


FIELD FIELD FIELD DESCRIPTION 
NAME TYPE LENGTH/ OF FIELD 
DECIMALS 





TDA PARA NUMERIC TDA PARAGRAPH NUMBER 


ono WT 
aurÍ mos (CHARACTER |e |o [MILITARY OCCUPATIONAL SPECIALTY CODE 


ABSENCE FILE 


TDA LINE NUMBER 


TDA POSITION NUMBER 


OFFICIAL JOB TITLE AS STATED ON TDA 






ACCOUNT PROCESSING CODE 


AUTHORIZED BRANCH OF SERVICE 








FIELD DESCRIPTION 
LENGTH/ OF FIELD 
DECIMALS 


rx Jess L3z lr rISCAL YER OF ABSENCE REQUEST | 
emo [pas | e |o [em vare or apsence 
purarzon  |womerte JL: La Jana (START DATE - END DATE) | 
coments Jesse | 30 | o |comenrs apouT ABSENCE REQUEST — 


CMEALLOC FILE 






























FIELD FIELD FIELD DESCRIPTION 
NAME TYPE LENGTH/ OF FIELD 
DECIMALS 







FISCAL YEAR OF CME FUNDS ALLOCATION 
ALLOCATION |MONEY 


CME FUNDS ALLOCATION FOR THE FY 





[2 jo 
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CMEREO VFI 


FIZLD FIELD FTELED DESCRIPTION 


TYEE 


LENGTH/ OF FIELD 





DECIMALS 


| 5 | 0 |personwen IDENTIFICATION CODE | 
| 2 [0 |rrscan vear or meQUEST | 
| 1 | 0 [ryre or cum Request (ONE DIGIT CODE) 
eo START DATE OF CME TRAVEL 
a o 
PA 
20 
"os nw 


IDCODE CHARACTER 


NUMERIC 


"nj 
H 


TYPE CHARACTER 
START 


END 


g ju 
poi» 
H H 
D Ip 


LOCATION OF REQUESTED CONFERENCE 
le io 
ENEMIES a 


TRAVELCOST |MONEY y 2 COST OF TRAVEL 


mene [mouy | e |2 [remsursapre exeenses 
Torarcosr Jee | e |2 |reavencosT+PERDIEMtREGFER+REIMP 00 
c cops  [cmmrmcren | 1 | o Jee oe (asacruaL OR E=ESTIMATED) 


ABSENCE FILE 


DURZTION NUMERIC 


LOCATION CHARACTER 












FIELD FIELD FIELD DESCRIPTION 
NAME THE LENGTH/ Or FIELD 
DECIMALS 





0 PERSONNEL IDENTIFICATION CODE 


IDCODE CHARACTER | 


5 
ees Jee | e 
a 


FISCAL YEAR OF ABSENCE REQUEST 


TYPE OF ABSENCE (CODED) 


EE START DATE OF ABSENCE 


mo Je 
DURATION NUMERIC 
COMMENTS CHARACTER 


END DATE OF ABSENCE 
CALCULATE (START DATE - END DATE) 


COMMENTS ABOUT ABSENCE REQUEST 


St 


SATISFACTION DATABASE FILE 











SURVEY FILE 









FIELD DESCRIPTION 
LENGTH/ OF FIELD 
DECIMALS 


WONT 


YEAR NUMERIC YEAR SURVEY TAKEN 


SECTCODE CHARACTER rx SECTION CODE (FROM SURVEY) 
DOCTORNAME |CHARACTER DENEN DOCTOR'S LAST NAME, FIRST NAME, MI 







MONTH SURVEY TAKEN 









ACCAPPT NUMERIC 
RECORDS 1 WERE MEDICAL RECORDS READY? 

acemarr Jager | 1 |o bessa o WAITING TIME SCORE | 
prcser_ |wmerro | 1 | 0 |courresy or RECEPTIONIST SCORE — 
surse |mumerre | 1 |o [courres or nurses score 0 
pocrors [morte | 1: |o [courtesy or pocrons score 
Exams [nomere | 1 |o Jane or PROCEDURES SCORE — 
rivesrent Joes: | 1 |o |abzouacy of TIME SPENT WITH DOCTOR SCORE 
crean |womemte | 1 |o Jersawprwess or om scone 
eng |wwerre | 1 |o [eemeran SATISFACTION ze. 
parcomment |cuaracter | 1 | o [ame THERE PATIENT COMMENTS TO ENTER? 
comenrs [meno |10 | o [comennes memo rrero 


SCORE : NUMBER MARKED ON PATIENT'S SURVEY QUESTIONNAIRE 


ACCEPTABILITY OF DAYS TO GET APPOINTMENT 


1 
a 
H 
n 















RES 


PRODUCTIVITY DATABASE FILE 


Vist FILE 


FIELD FIELD FIELD DESCRIPTION 
NAME TYPE LENGTH/ OF FIELD 
DECIMALS 


mo |NUMERIC E MONTH OF VISIT INFORMATION 
SECTCODE CHARACTER ME a SECTION CODE 
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APPENDIX B. DISPLAY SCREENS 


LIST OF SCREENS 


ABSENCE SCREEN FILE 
APC SCREEN FILE 
CHOICE SCREEN FILE 
CMEALLOC SCREEN FILE 
CMEREQ SCREEN FILE 
CONFIRM SCREEN FILE 
DELCMERE SCREEN FILE 
DELLEAVE SCREEN FILE 
DELMOEXP SCREEN FILE 
DELQALLO SCREEN FILE 
EQUIPMENT SCREEN FILE 
EQUIPMENT UPDATE FROM RIR SCREEN FILE 
MOEXP SCREEN FILE 
OCCUPIED SCREEN FILE 
PERRIR B SCREEN FILE 
PERSON SCREEN FILE 
POSITION SCREEN FILE 
QTRALLOC SCREEN FILE 
SOCIAL SCREEN FILE 
SURVEY SCREEN FILE 
TDA SCREEN FILE 
TDAINPUT SCREEN FILE 
UPCMEREQ SCREEN FILE 


ABSENCE SCREEN FILE 


Update and change the absence information in the Personnel Database. 


21 SAY "UPDATE LEAVE OR ABSENCE REQUEST" 

4 SAY "This is the Fiscal Year" 

28 SAY  ABSENCE--EY PICTURE "99" 

31 SAY “Leave or Absence request for ID CODE" 

SAY ABSENCE->IDCODE PICTURE "!9999" 

23 SAY "Type of Request" 

46 GET ABSENCE->TYPE PICTURE "15 

4 SAY "L..Regular Leave E. .Emergency Leave T..Other TDY noto CMES 
4 SAY "P..Permissive TDY C..Convalescent Leave O..Other" 
SAY "Starting Date" 

GET ABSENCE->START 

SAY "Ending Date" 

GET ABSENCE->END 

SAY "Duration" 

SAY ABSENCE->DURATION PICTURE "999" 

SAY "days" 


~ ~ ` mm ~ ~ ~ ~ ~ 
a 
00 


QJ) XO OO OY OY Q) Q9) Y y O 


m 

"mm 
m. 
m 


DDO DODOA 
mm 
W W 
"mm ~ ~ € mm 
WN UN 
WA ON 


RRR RR Fa 
J3NO 0UnN nn y 
mmm 
W 
O 


7, tS SAY "COMMENT" 

, 253 GET ABSENCE->COMMENT FUNCTION “!“ 
LOA 

IO O 


APC SCREEN FILE 


Update and chanae the Account Processina Code information in the Budget Database. 


@ 2, 23 SAY "APC Code Entered ->" 

@ 2, 44 SAY APC->APC FUNCTION "R" PICTURE "A-999" 
Q S, 8 SAY "SECTION" 

@ 5, 20 GET APC->SECTION 

@ 5, 48 SAY "Section Code" 

@ 5, 63 GET APC->S CODE 

Q 8, 20. SAY “Point of Contact” 

@ 8, 38 GET APC->POC 

Q 11, 20 SAY "Telephone Number" 

€ 11, 38 GET APC->TELEPHONE PICTURE "(999) -999-9999" 
Q 14, 31 SAY "Sec" 

@ 15, 30 SAY "SECTION CODES* 
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Q 16, 4 SAY "Family Practice Clinic FFC Consolidated Troop Clinic CTM" 
Q 17, 4 SAY "General OutPatient Clinic GOC Fore Hunter Liggett Clinic FHL" 
(eee SAY "CTMC-Family Practice CFP Ambulanze Section AMB" 
@ 19, 4 SAY “Emergency Medical Service EMS Flight Surgeon Office ESO" 
@ 20, 4 SAY "Presidio of Monterey POM Department DEP" 
EU I TO 13, 78 DOUBLE 

ma TO 3, 77 

ENT I. TO 21, 78 


CHOICE SCREEN FILE 


Generic user selection format for the Personnel Database. 


ESTO SII, 79 DOUBLE 

@ 710 SAY "ENTER YOUR CHOICE" 

@ 8,10 SAY "1. MOVE THE OLD PERSON TO EXCESS AND THE NEW PERSON INTO THE SLOT" 

Q 9,10 SAY "2. PLACE THE PERSON YOU ARE WORKING WITH INTO THIS POSITION AS EXCESS ( OVERSTRENGTH, 
EOGCIITSONOCODE = 99)" 

@ 10,10 SAY "3. TRY ANOTHER POSITION " 

Q 7,28 GET ANSWER PICTURE "9" RANGE 1,3 


CMEALLOC SCREEN FILE 


Update and change the Continuing Medical Information funds allocation in Personnel Database. 


28 SAY "UPDATE CME ALLOCATION" 

9 SAY "THE CME ALLOCATION FOR FISCAL YEAR" 
44 SAY CMEALLOC->FY 

AN SAY -“SHOULD BE $° 

59 GET CMEALLOC->ALLOCATION 

SERTO 7], 73 DOUBLE 


DODDO 
w ANU a e 


mm = U€t 00 a y 


CMEREQ SCREEN FILE 
Update and change the CME request information in the Personnel Database. 


2 SAY "SUBJECT: APPLICATION FOR CONFERENCE/MISSION TRAVEL IN FISCAL YEAR" 
CSAY M FY PICTURE "99" 
O SAY “l. Type of Travel Requested....... S 
34 GET CMEREO->TYPE PICTURE "!" 
3 SAY "C-Conference/Meeting Travel G-General Mission Travel B-Board Certificatio" 
O SAY "2. ID CODE of person requesting the travel is" 
HAY M-IDCODE PICTURE "!9999" 
Bee SAY "." 
O SAY "4. Purpose of Travel is" 
24 GET CMEREO->PURPOSE 
8, 45 SAY ". 5. Registration Fee $" 
8, 71 GET CMEREQ->REGFEE 
10, 0 SAY "6. Destination" 
10, 16 GET CMEREQ->LOCATION 
10, 42 SAY "Mode of Travel is" 
10, 60 GET CMEREO->TVLMODE 
IMAZ” SAY "F-FLY, G-GOVT VER, P-POV, O-OTHER" 
13, O SAY "8. Leave Dates Starting Date" 
ISI GET CMEREO->START 
13, 41 SAY "Ending Date" 
150053 GET .CMEREO-^END 
14, 3 SAY "Duration" 
14, 14 SAY  CMEREQ-»DURATION 
14, 19 SAY "days" 
IU SAY "13. TRAVEL COST $" 
16, 18 GET CMEREQ->TRAVELCOST 
MO. SAY “PER DIEM COST $" 
16, 44 GET CMEREQ->PERDIEM 
16, 56 SAY "REIMBURSABLES $" 
EO] GET CMEREO->REIMB 
iy? SAY “TOTAL COST OF TRAVEL $" 
18, 40 SAY CMEREQ->TOTALCOST 
20, 12 SAY “EXPENSES REFLECT THE" 
EMONCODE - "A" 
Q 20, 33 SAY "ACTUAL COST OF TRAVEL" 
ELSE 
1250/33. SAY "ESTIMATED COST OF TRAVEL" 


Oc OO OY Oh y y AR 


t wr yy 9 am = am = € 0 


HÀ (e (e (2D (2D (CO (ED (CD (ED. (6D. (0D. (8. (02 (0D. (02. (02. (0D. (02. (0. (02. (0D (02. (0D. (0D. (02. (OD. (5 O (02 O DO OD 
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ENDIF 
e 0, O TO 2, 79 
@19, 10 TO 21, 58 


CONFIRM SCREEN FILE 


Generic confirmation screen for the Personnel Database. 


4,0 SAY MESSAGE 

6,0 TO 9,79 DOUBLE 

7,5 SAY "Last Name: "+LNAME 

7,35 SAY "First Name: "+FNAME 
8,5 SAY "Rank: "+RANK 

8,35 SAY "Branch: "+BRANCH 

?? CHR(7) 

G 1570 

WAIT "PRESS RETURN TO CONTINUE..." 


OAD ® ® @® 


DELCMERE SCREEN FILE 


Special delete CME request information screen in Personnel Database. 


2 SAY "SUBJECT: DELETE APPLICATION FOR CONFERENCE/MISSION TRAVEL IN FISCAL YEAR" 

68 SAY M FY PICTURE "99" 

O SAY "l. Type of Travel Requested....... z 

34 SAY CMEREQ->TYPE PICTURE "L9 

3 SAY "C-Conference/Meeting Travel G-General Mission Travel B-Board Certificatio" 

O SAY "2. ID CODE of person requesting the travel is" 
SAY CMEREO->IDCODE PICTURE "!9999" 

SZ E SAY" 

O SAY "4. Purpose of Travel is" 

SAY  CMEREO->PURPOSE 

15 SAY ^"; 5. Registration Fee $" 

SAY  CMEREQ-^REGFEE 

SAY "6. Destination" 

, 16 SAY CMEREQ->LOCATION 

, 42 SAY "Mode of Travel is" 

, 60 SAY  CMEREO->TVLMODE 

Il, 42 SAY “E-FLY, “CSGOVT VEN, PB=EOY, OZOTHERS 

13, O0 SAY "8. Leave Dates Starting Date" 

SAY CMEREO->START 

13, 41 SAY “Ending Date" 

13, 53 SAY CMEREQ->END 

14, 3 SAY "Duration" 

14, 14 SAY CMEREQ->DURATION 

14, 19 SAY "days" 

16, 0 SAY "13. TRAVEL COST $" 

16, 18 SAY CMEREO->TRAVELCOST 

16; 29% SAY “PER DIEM COsT Ss" 

16, 44 SAY CMEREQ->PERDIEM 

16, 56 SAY "REIMBURSABLES $" 

16, 71 SAY CMEREQ->REIMB 

18, 17 SAY “TOTAL COST OF TRAVEL $” 

18, 40 SAY TOTALCOST 

20, 17 SAY "DO YOU WANT TO DELETE THIS RECORD"; 

GEI MAYBE PICTURE "i" 

0, O TO 2, 79 

19, TO CTO OB 


mm nm mm mm mm +. . +. +. B® y 
N D 
I o 


= 
~ 
kA 


AAA kä 
0000000 0 Oh ch Oh yy rp 
© 


(e cu DO DO DD DO (CAD COD CD (CAD CD CD COD CA Cm) DY DD DO DOI YODA 
HP 
GJ) 
mm 
LA) 
i 


DELLEAVE SCREEN FILE 


Special delete Absence information screen for the Personnel Database. 


, 21 SAY “UPDATE LEAVE OR ABSENCE REQUEST" 
e 4 SAY "This is the Fiscal Year" 
28 SAY ABSENCE->FY PICTURE "99" 
31 SAY "Leave or Absence request for 1D CODE" 
SAY ABSENCE->IDCODE PICTURE "!9900" 
23 SAY "Type of Request" 
46 SAY ABSENCE->TYPE PICTURE ais 


(e (e (t 
Oh Oh GA GA y uy O 
mm mm » ha ww 

o 

oo 
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(zo 
e 

~ 
de 


IL 


(e (2D (QD DDD DD DD DY DO (m) Cm 
Hp 
Un 
mm 
LA 
o 


SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
TO 


"L..Regular Leave E. .Emergency Leave 
"P..Permissive TDY C..Convalescent Leave 
Eotanting Date" 


ABSENCE->START 

"Ending Date" 

ABSENCE->END 

"Duration" 

ABSENCE->DURATION PICTURE "999" 
"days" 

"COMMENT" 

ABSENCE ->COMMENT 

a. 15 


mo 10, 72 


SAY 
GET 


"DO YOU WANT TO DELETE THIS FECOFD"; 
MAYBE PICTURE "!" 


923, 58 


DELMOEXP SCREEN FILE 


T. Other TDY, not 
O... Other" 


Special delete Monthly Expenditure format for the Budget Database. 


220 
26 
38 
26 
38 


mm mm 


(e (CD (2D CE C CO D (moc»:to 
VO OD VG VO IO nn 
zm = 9 . & 

UJ 

ceo 


ere 


SAY "Delete this Monthly Expenditure" 
SAY "APC Code" 
SAY MOEXP->APC FUNCTION "!" PICTURE "A###* 
SAY "Month" 
SAY MOEXP->MONTH 
SAY "Expenses" 
SAY MOEXP->EXPENSES 
TO 10, 56 DOUBLE 
TO 20,59 
SAY "Delete this Record? (Y/N) "> 


GET Maybe PICTURE "!" 


DELQALLO SCREEN FILE 


Special delete quarterly allocation format for the Budget Database. 


19 


OO Min LA 

mm = =» wm © 
D N GA 
kA OO 


DDD (0) DD (ED (DY (0D (0D (Cm Cm C fa @ 
Pp 
| 
= 
UJ 
VO 


SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 
SAY 


"Delete the Quarterly Allocation" 
"tor" 

"Fiscal Year" 

QTRALLOC->FY 

"Quarter" 

OTRALLOC->QUARTER 

"APC Code" 

QTRALLOC->APC 

"Allocation" 

OTRALLOC->ALLOCATION 


TO 16, 59 DOUBLE 


To 


Nee e8 


mon20, 29 


SAY 


"Delete this Record? (Y/N) "; 


GET Maybe PICTURE ^!" 


EQUIPMENT SCREEN FILE 


Update and change the Equipment information in the Equipment Database. 
[EMENU1 1 SCREEN FILE] 


dE 
25 
44 


DOADAADADA DAA ®® 
O O WI Ie onsite) 
=~ r "mw mm wm ww 02 mm ww = = © 
| 
- 


H 

- 
N 
eo 


SAY 
SAY 
GET 
SAY 
GET 
GET 
GET 
GET 
GET 
GET 
SAY 
GET 
SAY 
GET 


SESNUT. E E NEW El eeh DA T.A?” 


DBEODDIEMEHJI CODE 4" 
EQUIP--EQCODE 


"SECT DATE ITEM DESCRIFTION TYPE 


ENUTE=>SECTCODE 

EQUIP->REQDATE 

EQUIE S>DESCRIPT 

EQUIP->REQTYPE 

EQUIP ->URGCODE 

EOUIPZSZSOTYI 

"ST 

EQUIP->UNITPRICE 

"STATUS CODE COMMENTS" 
EQUIP->STATUS 
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URGENCY ONY 


CME” 


UNIT PRICE" 


E 10, 41 GET EQUIF->COMMENTS 

E 14, 7 SAY "URGENCY CODES TYPE: OP" PEOUESTCODES STATUS CODES" 

GQ 16, Se Say a0 Needed Now EISE MEDCASE FW Paperwork" 
Gal, 6 SAY "1 1 Year CEEF CEEF Fli RMD" 

Cmo ON SAYSST 2 Years CAPR CAPR AP Approved " 
Q 19, 6 SAY "3 3 Years OTHE OTHER OO On Order" 
@ 20, 6 SAY "4 Not Urgent RC Received" 
Q P3. <4) -1O AZ 

Gs, 2b O Zilly S2 

C5155) 29> El 

a top S O Lon Z 

g 1, 0 TON 9 DOUBLE 

@ 3p. TONS 8 

Q 13, SEA WE Aly VS 

8 15,599 TOL et 

Q5. 24 TO 5, S] 


EQUIPMENT UPDATE FROM RIR SCREEN FILE 


Special update screen for Equipment when the Resource Information Report is used. 
[EMENU2 2 SCREEN FILE] 


pal ¿SAY "SECTION? 

, 42. SAY  EQUIP-»SECICODE 

e 9 SAY "EQUIP CODE ITEM DESCRIPTION SES UNITPRICE STATUS" 
, 10 SAY EQUIP—>EOCODE 

, 21 SAY EQUIP->DESCRIPT 

, 44 GET EQUIP->OTY 

, 90 GET | EQUIP=>UNITEPRICE 

, 64 GET EQUIP->STATUS 

10, 33 SAY "COMMENTS" 

11, 27 GET EQUIP->COMMENTS 

14, 12 SAY "Press ESC to abort editing, ENTER to complete changes." 
SE 72 DOUBLE 

4, 6 TO 4, 70 


DD DDD DY DO DDD 


MOEXP SCREEN FILE 


Update and change the monthly expenditures in the Budget Database. 


H 2, 22 SAY "Enter the Monthly Expenditure" 

@ 5, 26 SAY "APC Code" 

H 5, 38 SAY MOEXP->APC FUNCTION "!" PICTURE "A444" 
@ 7, 26 SAY "Month" 

@ 7, 38 SAY MOEXP->MONTH 

@ 9, 26 SAY "Expenses" 

@ 9, 38 GET MOEXP->EXPENSES 

@ 1, 15. TO 10.556 DOUBLE 

8.21," 15. TO324, 7756 


OCCUPIED SCREEN FILE 


Special output screen when a TDA position is occupied in the Fersonnel Database. 


O TO 11, 79 DOUBLE 

5 SAY "THAT POSITION IS ALREADY OCCUPIED BY: " 
5 SAY "Last Name: "+LNAME 

5 SAY "First Name: "+FNAME 

0,5 SAY "Rank: "+RANK 

o O 


, 
, 
, 
€ 


@ 6 
@ 7 
e 8 
@ 9 
e 1 
@ 

W 


PERRIR B SCREEN FILE 


Special input screen for personnel information when the Resource Information Report is Used. 


24 SAY "UPDATE FROM R.I.F. REPORT" 
O SAY "B. CHANGES TO CURRENT TIA (OTHER THAN LOSSES OR GAINS)" 

22 SAY "OLD POSITION NEW FOSITION" 

2 SAY "PARA LINE POSN  IDCODE LAST NAME RANK PARA LINE POSN" 
3 GET O TDA PARA PICTURE "999" 


DDD DO 
VO TN We 


~ = = ~ mm 


208 


10 GET O TDA LINE PICTURE "99" 

17 GET O TDA POSN PICTURE "99^" 

23 GFT M JDCODE PICTURE “!0999* 

31 GET M LNAME PICTURE ^!1!111!!!!)!)!1111]!11]1^ 
55 GET M RANK PICTURE "!1I" 

GET M TDA PARA PICTURE "999" 

GET M TDA LINE PICTURE "99" 

GET M TDA POSN PICTURE "99" 


mm mm = mm = 


a a a 
zl On Ch 
Oh o hi 


gp 9 

p 9 

a o 

e 9 

@ 9 

p 9 

p 9 

H 9 K 

Q 13, 18 SAY "PRESS RETURN (BLANK ALL ENTRIES) TO QUIT" 
mE To o, 7 

I4 TO 9, 14 
[TO 9, 21 

@ 7, 29 TO 9, 29 

A. TO 9, 52 

@ 7, 66 TO 9, 66 

AA TO 9, 73 

Q 5,59 TO 9, 59 DOUBLE 
AA O TO 10, 79 DOUBLE 
TO 6, 78 

Q 8, 1 TO 8, 78 

UE TO 2, 52 


PERSON SCREEN FILE 


Update and change personnel information in the Personnel Database. 


0, 28 SAY "UPDATE PERSONNEL” 

IE -^Y "ID CODE is" 

15 SAY PERSON->IDCODE 

5 SAY "Last Name First Name MI RANK BRANCH MOS" 
5 GET PERSON->LNAME 

28 GET PERSON->FNAME 

48 GET PERSON->RANK 

56 GET PERSON->BRANCH 

GET PERSON->MOS 

SM SAY “Arrival Datesen... e 

GET PERSON->ARRDATE 

SAY "Anticipated Date of Loss..." 

, 65 GET PERSON->ALOSS 

12, 18 SAY “INDIVIDUAL IS ASSIGNED TO TDA POSITION" 
SAY "TDA Paragraph Number is" 

14, 47 SAY PERSON-»2TDA PARA 

855 23 SAY "TDA Line Number is" 

15, Y2 SAY PERSON->TDA_LINE 

16, 23 SAY “TDA Position Number is" 

16, 46 SAY PERSON->TDA_POSN 

38, 6 SAY "NOTE: If Position Number is 99, the Individual is carried as excess" 
Ec TO 17, 37 


mm mm a 09 BS & 


e 
Un 


= = 
ho 
LA 


00 0D OO 0 4n Ui Qi Ot On o PO P2 
LA 
co 


DODADDDADA OOO O O DO DO O ODO (ei (éi (ei Téi (éi CE CE CE Cv 
= 
da 
- 
N 
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fa TO 6, 74 

4, 53 TO 5, 53 

4,62 TO 5, 62 

4, 45 TO 5, 45 

4, 26 TO 5, 26 

PENES ro 10, 75 DOUBLE 


POSITION SCREEN FILE 


TDA position verification output screen for the Personnel Database. 


@ 32,0 TO 17,79 DOUBLE 

@ 23,5 SAY “THE POSITION CHOSEN WAS: " 
RAN SAY “Job Title: "*JOB TITLE 

@ 35,5 SAY "Authorized Branch: "+A"TH RR 
@ 15,30 SAY "Authorized Grade: “+AUIH GR 
Q 14,5 SAY “Authorized MOS: "+AUTH MOS 

Q 16,30 SAY "Authorized Position: " 

ak 


F AUTH = 1 

Er "YES" 
ELSE 

gir ENGT 
ENDIF 


Q 22,0 WAIT 
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OTRALILOC SCREEN FILE 


Update and change quarterly allocation in the Budget Database. 


7 199 AT 
, 34 SAY 
, 28 SAY 
, 41 SAY 
27 SAY 
, 39 SAY 
SAY 
11, 39 SAY 
e SAY 
13, 39 GET 


"Enter the New Quarterly Allocation" 
"fors 

"Fiscal Year" 

QTRALLOC->FY 

"Quarter" 

OTRALLOC->QUARTER 

"APC Code" 

QTRALLOC->APC 

"Allocation" 

OTRALLOC->ALLOCATION 


1, 014 T0 716,059 DOUBLE 


OOOO OO Ooo @ @ wD 
= 
= 
N 
~J] 


IA LOTO 


77208 


SOCIAL SCREEN FILE 


Update and change personal information in the Personnel Database. 


12 SAY 
oon OF SAY, 
OO SAY 
fr Ome Say 
a 3 SAY 

3 SAY 

O0 SAY 
j 3 SAY 

2 SAY 

13 GET 

38 SAY 
11, 50 GET 
Ke 2 SAY 
GET 
CO 
13, 47 GET 
13, 51 GET 
15, 18 SAY 
15, 35 GET 
E: 2 SAY 
ey ta GET 
1), 29 SAY 
I7, 52 GET 
19, 10 SAY 
19, 27 GET 
0, 0 TO 


ADA DADA DADA DADA AO OOO ®@ OO (ei éi (éi BD 
m 
Go 
FA 
un 


"This is the personal information for ID CODE" 

FRIVATE-»IDCODE PICTURE "19999" 

"PRIVACY ACT STATEMENT" 

"PRINCIPLE PURPOSE: To maintain personal information on indivduals assigned to" 
"this command to facilitate counseling, emergency notification, and social" 
"event information." 

"WARNING: This information is of a highly sensitive nature and should not be" 
"provided to anyone outside of the chain of command without approval." 
"Address" 

PRIVATE->ADDRESS FUNCTION "!" 

"Telephone" 

PRIVATE->TELEPHONE FUNCTION "R" PICTURE "(999)999-9999* 

"City, state, Zipi coder 

PRIVATE=>CITY 

, 

PRIVATE--SSTATE 

PRIVATE->ZIPCODE FUNCTION "R" PICTURE "99999-9999" 
"Date of Rank" 

PRIVATE->DOR 

"Wife’s Name" 

PRIVATE->WIFE 

"Children’s Names/Ages" 

PRIVATE->CHILDREN FUNCTION "S24" 

"Comments" 

PRIVATE->COMMENTS 

27137 


10." 0° TO 20,77 


SURVEY SCREEN FILE 


Input screen for the Patient Satisfaction Survey in the Satisfaction Database. 


Q1, CI SAY 
@ 1, 13 GET 
@ 1, 18 SAY 
@ 123 GEL 
@ 1, 29 SAY 
@ 1, 36 GET 
@ 1, 43 SAY 
@ 1, 51--GET 
@ 3, 18 SAY 
@ 3, 58 GET 
@ 4, 20 SAY 
@ 4, 58 GET 
@ 6, 18 SAY 
@ 6, 58 GET 
@ 8, 18 SAY 
E 8, 38 GET 
dg 9, 20 SAY 
Q 9, 58 GET 


"MONTH" 

SURVEY->MONTH RANGE 1, 12 

"YEAR" 

SURVEY -»YEAR 

SELINTES 

SURVEY-ZSECTCODE 

"DOCTOR" 

SURVEY->DOCTORNAME 

"l.A. Days to get appointment. l.A." 
SURVEY->APPTDAYS RANGE 1, 6 

"B. Acceptability. B.” 
SURVEY->ACCAPPT RANGE 1, 2 

ÉS Records ready on time. ng 
SURVEY->RECORDS RANGE 1, 2 

"3.A. Waiting time. SALT 
SURVEY->WAITTIME RANGE 1, 4 

"B. Acceptability. BS 
SURVEY->ACCWAIT RANGE 1, 2 
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INES. SAY "4, Courtesy, receptionists. 4." 
11, 558 GET SURVEY~->RECEPT RANGE 1, 5 


IA LAY "5. Courtesy, nurses. m 
12, 58 GET SURVEY--NURSE RANGE 1, 5 
IESUS SAY "6. Courtesy, doctors. Kee 
13, 58 GET SURVEY->DOCTORS RANGE 1, 5 
14, 18 SAY "7. Explanation of procedures. qut 
14, 58 GET SURVEY->EXPLAIN RANGE 1, 5 
MOTE. SAY "8. Time spent with doctor. Bos 
15, 58 GET SURVEY->TIMESPENT RANGE 1, 5 

SAY "9. Cleanliness. o 
16, 58 GET SURVEY->CLEAN RANGE 1, 5 
EE. SAY "10. General satisfaction. 10." 


17, 58 GET SURVEY->SATIS RANGE 1, 5 

20, 20 SAY “ARE THERE COMMENTS TO ADD? (INS 
20, 58 GET SURVEY->PATCOMMENT 

AUS SAY "(Cntrl PgDn to Enter Comments)" 
21, 55 GET SURVEY->COMMENTS 

DUX TO 22, 73 DOUBLE 

EENIS C TO 10, 60 

MOSES TO 18, 60 


DD DO DY O DY DD Y YO DY DY DO YO DO DD YD 
o 
= 
pa 
eo 


TDA SCREEN FILE 


Update and change the TDA information in the Personnel Database. 


Zee SAY “TDA Listing" 
4, 10 SAY "Paragraph Number" 
4, 27 SAY TDA-»TDA PARA 
; 94 DANS EOSITION TITLE" 
, 10 SAY "Line Number" 
, 28 SAY  TDA-»TDA LINE 
MAT. SAY “Job Title" 
, 59 GET TDA-»JOB TITLE 
, 10 SAY "Position Number" 
, 28 SAY TDA->TDA_POSN 
, 26 SAY "POSITION CHARACTERISTICS" 
14, 24 SAY "APC Code" 
14, 46 GET TDA-»APC 
SAY "Authorized Branch" 
15, 46 GET TDA->AUTH BR 
16, 24 SAY "Authorized Grade" 
16, 46 GET IDA-»AUTH GR 
17, 24 SAY "Authorized MOS" 
1/46 GET TDA--AUTH MOS 
18, 24 SAY "Position Authorized" 
18, 46 GET TDA->AUTH 
19, 29 SAY "1sYES  OzNO" 
E TO 9, 34 
oss TO 6, 44 
ENS TO 7, 79 
m TO 20, 55 


(aD (c) (eO (m) (cO (cO (QD DY DY Y (Y Y (Y DY Y Y (0 (Y) (Y) (Y (Y) (Y (DY (ei (ei (ei 
Pp 
Un 
N 
D 


TDAINPUT SCREEN FILE 
Input screen for entering a requested TDA position in the PErsonnel Database. 


@ 6,0 TO 11,79 DOUBLE 
@ 7,5 SAY "WHAT POSITION WILL THIS PERSON OCCUPY ; 
OR ENTER A ZERO (0) TO QUIT: " 
@ 8,5 SAY "TDA Paragraph Number:" ; 
Ser TPAPARA PICTURE "999" 
READ 
*= SEE IF THEY WANT TO QUIT 
IF M TDAPARA = 0 
TRY-.F. 
LOCP 
ENDIF 
@ 9,5 SAY "TDA Line Number:" ; 
GET M TDALINE PICTURE "99" 
@ 10,5 SAY "TDA Position Number:" ; 
GET M TDAPOSN PICTURE "99" 
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UPCMERFO SCREEN FILE 


Special update screen for CME requests when only actual costs are entered in Personnel Database. 


Q 2 SAY "SUBJECT: APPLICATION FOR CONFERENCE/MISSION TRAVEL IN FISCAL YEAR" 

Q 68 SAY AMSEY PBIETURE SOS 

@ O SAY "1. Type of Travel Requested......." 
@ 34 SAY CMEREQ->TYPE PICTURE "*"!" 

@ 3. SAY "C-Conference/Meeting Travel G-General Mission Travel B-Board Certificatio" 
@ SAY "2. ID CODE of person requesting the travel is" 
Q 46 SAY M_IDCODE PICTURE "!9999" 

(a SOA KE 

Q O SAY "4. Purpose of Travel is” 

Q 24 SAY CMEREQ->PURPOSE 

Q dor ¡SAM 5. Registration Fee $" 

Q , 11 GET CMEREQ->REGFEE 

4 10, O SAY "6. Destination" 

@ 10, 16 SAY CMEREQ->LOCATION 

@ 10, 42 SAY "Mode of Travel is" 

@ 10, 60 SAY CMEREQ->TVLMODE 

a 11, 42 SAY "F-FLY, G-GOVT VEH, P-POV, O-OTHER" 
@ 

@ 

Q 

@ 

Q 

e 

Q 

Q 

Q 

Q 

Q 

@ 

@ 

Q 

Q 

e 

M 


- mm = Mm Y = = © - a 


0 0 OD On Oh Oh iy PR H3 


13, 0 SAY "8. Leave Dates Starting Date" 
13, 31 SAY “CMEREO->START 
13, 41 SAY “Ending Date" 
13, 53 SAY CMEREO->END 
1450-359 SAY "Duration 
14, 14 SAY CMEREQ->DURATION 
14, 19 SAY "days" 
16, 0 SAY "I3. STRAVEDLSCOSTESS 
16, 18 GET CMEREQ->TRAVELCOST 
16, 29 SAY SUPER (DGEM Cost ss: 
16, 44 GET CMEREQ->PERDIEM 
16, 56 SAY "REIMBURSABLES $" 
16, 71 GET CMEREQ->REIMB 
18, 17 SAY “TOTAL COST OF TRAVEL S» 
18, 40 SAY CMEREQ->TOTALCOST 
20, 12” SAY O"EXPENSESSREBPEECTOTHESS 
F € CODE = “A? 
dd 20,33. SAY TACTUALTCOST OF TRAVEL? 
ELSE 
a 20,33 SAY "ESTIMATED COST OF TRAVEL" 
ENDIF 
Qu 0r E 
ES 10" ?TOST21, 758 


2:17 


APPENDIX C. 


TABLE OF PROGRAMS 


BMENU . P RG 
BMENU1 . PRG 
BMENU2 . PRG 
BMENU3 . PRG 
BMENU4 . PRG 
BMENU4 1.PRG 
BMENU4 2.PRG 
BMENU4 3.PRG 
BMENU4 4.PRG 


DISCLAIMER 


The purpose of this programming code is to 
facilitate the understanding of the 
requirements presented in Chapter 5 of this 
thesis. The nature of this project precludes 
it actual implementation in DBASE III+. To 
fully implement the requirements the system 
designer will need a full range of capabilities 
that does not currently exist in DBASE III+. 

DBASE III+ served as the modeling tool by 
which the screens were generated and where 
necessary, specific code was written to 
illustrate a point. The actual working code 
merely acts as a shell in which to run the 
menus. A close analysis of the program code can 
facilitate implementation in a more suitable 
language, i.e., PARADOX, which can support the 
graphics and high level relationships involved 
in the various databases. Where the actual 
requirements process may appear to be unclear, 
comments were added within the code to explain 
these areas to the designer. 


* Program..: 
BKENU.PRG 


* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 

* Date.....: 02/14/89 

* Notice...: Copyright (c) 1989, ELBERT T. SHAW & JOAN 
ZIMMERMAN, All Rights Reserved 

* Notes....: The main engine menu for the Budget System 
SET TALK OFF 

SET BELL OFF 

SET ESCAPE OFF 

SET CONFIRM ON 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
x draw menu border and print heading 
CLEAR 


6 2, O TO 14,79 DOUBLE 

@ 3, 18 SAY (DEPARTMENT OF FAMILY PRACTICE BUDGET SYSTEM] 
@ 4,1 TO 4,78 DOUBLE 
---display detail lines 

7,29 SAY (1. UFDATE FISCAL YEAR ALLOCATIONS) 
8,29 SAY [2. UFDATE MONTHLY EXFENDITURES) 
9,29 SAY [3. UPDATE APC INFORMATION FILE) 
10,29 SAY [4. PRINT REPORTS] 
12, 29 SAY 'O. EXIT’ 

STORE O TO selectnum 

@ 14,33 SAY " select z 

@ 14,42 GET selectnum PICTURE "9” RANGE 0,4 
READ 


DODOD » 


DO CASE 
CASE selectnum = O 
CLEAR ALL 
RETURN 


CASE selectnum = 1 


BUDGET PROGRAMS 
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* DO UPDATE 
DO BMENU1 
SET CONFIRM OFF 


WAIT 


FY ALLOCATIONS 


SET CONFIRM ON 


CASE selectnum = 2 
* DO UPDATE EXPENDITURES 
DO BMENU2 
SET CONFIRM OFF 


WAIT 


SET CONFIRM ON 


CASE selectnum = 3 
* DO APC INFORMATION FILE 
DO BMENU3 


SET CONFIRM OFF 


WAIT 


SET CONFIRM ON 


CASE selectnum = 4 


* DO PRINT REPORTS 


SET CONFIRM OFF 


WAIT 


SET CONFIRM ON 


ENDCASE 


ENDDO T 
RETORN 


* EOF: BMENU.PRG 


^ 


DO BMENU4 


* Program..: 


BMENU1 .PRG 
* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date.....: 02/14/89 
* Notice...: Copyright (c) 1989, ELBERT T. SHAW & JOAN 
ZIMMERMAN, All Rights Reserved * 
Notes....: Updates the Quarterly Allocation File 


SET TALK OFF 
SET BELL OFF 
SET ESCAPE OFF 
USE QTRALLOC 
M FY = © 


* Clear Screen for FY input an allow for the user to select 


the Fiscal Year 


* Typically, the user will only be operating in one FY 


CLEAR 


@6,0 to 8,79 DOUBLE 
@7,15 SAY "Enter the Fiscal Year for the Allocations:” ; 
GET M FY PICTURE "99" 


READ 

DO WHILE .T. 
* ---Display menu options, centered on the screen. 
E draw menu border and print heading 
CLEAR 


4 2, O TO 14,79 DOUBLE 


Q 3,6 SAY (UPDATE 


TION S) 


--di-ploy 
7,25 SAY [ 
8,25 SAY [ 
9,25 SAY [ 
10,25 SAY [{ 
12, 25 SAY 


DoDODDO + Bb 


4,1 TO 4,7€ DOUBLE 


FISCAL YEAR ALLOCA 


(der 311 lines 
ADD ALLOCATIONS FOR FY ) +STR (M_FY,2) 


13 
2. 
3. 
4. 
NO 


CHANGE 
REMOVE 
REVIEW 

EXIT’ 


STORE O TO selectnum 
select 
@ 14,42 GET selectnum PICTURE "9" RANGE 0,4 


@ 14,33 SAY " 
READ 


DO CASE 


CASE selectnum = O 
SET BELL ON 
SET TALK ON 


ALLOCATIONS FOF FY J+STF(M_FY,2 
ALLOCATIONS FROM FY )+STF(M FY, 2) 
ALLOCATIONS FOR FY )+STR(M_FY,2) 


Li 


CLOSE ALL 
CLEAR ALL 
RETURN 


CASE selectnum = 1l 


* 


DO ADD INFORMATION 


Adding = .T. 

DO WHILE Adding 
CLEAR 
M APC = SPACE (4) 


*- Get the Section the User wants to work with 
@ 6,0 TO 10,79 DOUBLE 
@ 7,10 SAY "Enter the APC Number of Section to 


enter its 


wë KE A 


allocation” GET M_APC PICTURE 
@ 8,10 SAY "or Press Return to QUIT" 
READ 


*-Nothing entered, so QUIT 
IF M APC -" " 

Adding = .F. 

LOOP 
ENDIF 


*-Make sure the APC exists in the Active File 
USE APC INDEX APC 
SEARCH= UPPER(M APC) 
LOCATE FOR APC#SEARCH 
IF FOUND () 
CLEAR 
@ 6,0 TO 9,79 DOUBLE 
@ 7,5 SAY "Section: "+SECTION 
@ 7,35 SAY "Section Code: "+S CODE 
@ 8,5 SAY "Point of Contact: "+POC 
8 8,35 SAY ; 


"Telephone: "+TRANSFORM (Telephone, ” (999) 999-9999") 


File,; 


to add 


restrict 


allocati 


ELSE 
*-Marn User that APC entered does not exixt 
CLEAR 
@ 6,0 TO 8,79 DOUBLE 


@ 7,5 SAY "APC requested is not in the Master 


Please Try again.” 
?? CHR{7) 
@ 15,0 
WAIT "Press Return to try again...” 
LOOP 
ENDIF 


*-Find out wish quarter’s allocation the user wants 


M OTR = 0 

@ 14,0 To 16,45 

Q 15,5 SAY "Enter the Quarter You Wish to Add: "; 
GET M_QTR PICTURE "9" 

READ 

USE QTRALLOC INDEX OTRALLOC 


*-Filter out all extraneous information and 
to user inputs 
SET FILTER TO FY=M FY .AND. QUARTER=M_QTR 
GO TOP - 
*-Check and see if the user has already enterd a 
on for this 
*-APC and Quarter 
LOCATE FOR APC=M_APC 
IF FOUND () 
CLEAR 
MAIT "RECORD ALREADY EXISTS, Press Return to 


Change it ” 


*-If found, just Edit the existing record 
SET FORMAT TO QTRALLOC 
READ 
CLOSE FORMAT 
ELSE 
*-Create a new record 
SET FOFMAT TO QTFALLOC 
CLEAR 
WAIT "ADDING NEW RECORD, Press Return to 


Continue” 
APPEND BLANK 
*-What the user has input, don’t make them 
reinput it 
REPLACE FY WITH M FY 
REPLACE APC WITH M APC 
REPLACE QUAPTER WITH M QTR 
READ RW 
CLOSE FORMAT 
ENDIF 
ENDDO 


SET FILTER TO 


file.." 


€ 5,0 SAY "Please stand by while I reindex the 


SET TALK ON 
REINDEX 

SET TALF OFF 
CLOSE ALL 

SET CONFIRM OFF 
WAIT 

SET CONFIRM ON 


CASE selectnum = 2 


k 


update i 


DO CHANGE INFORMATION 


Adding = .T. 
DO WHILE Adding 

CLEAR 
M APC = SPACE (4) 
Q 6,0 TO 10,79 DOUBLE 
€ 7,10 SAY "Enter the APC Number of Section to 

ts 

allocation” GET M_APC PICTURE "1999" 


@ 8,10 SAY "or Press Return to QUIT" 
READ 


IF MAPC =" " 
Adding = .F. 
LOOP 

ENDIF 


USE APC INDEX APC 
SEARCH] UFPER (M APC) 
*-Locate the APC and verify its existance 
LOCATE FOR APC#SEARCKR 
IF FOUND () 
CLEAR 
e 6,0 TO 9,79 DOUBLE 
@ 7,5 SAY "Section: "+SECTION 
@ 7,35 SAY "Section Code: "+S CODE 
€ 8,5 SAY "Point of Contact: "+POC 
€ 8,35 SAY ; 


"Telephone: "+TRANSFORM (Telephone, " (999) 999-9999") 


File,; 


restrict 


Change i 


Continue 


CA 
* 


ELSE 
CLEAR 
€ 6,0 TO 8,79 DOUBLE 
@ 7,5 SAY "AFC requested is not in the Master 


Please Try again.” 
?? CHR(?7) 
e 15,0 
WAIT "Press Return to try again..." 
LOOP 
ENDIF 


M QTR = O 
8 14,0 TO 16,45 
€ 15,5 SAY "Enter the Quarter You Wish to Change: 


GET M_QTR PICTURES 9A 
READ 
USE QTRALLOC INDEX QTRALLOC 
*-Filter out all extraneous information and 


to user inputs 
SET FILTER TO FY-M FY .AND. QUAPTER-M QTR 
GO TOP 
LOCATE FOR APC=M_APC 
IF FOUND į) 
CLEAR 
WAIT "RECORD ALREADY EXISTS, Press Return to 
t" SET FORMAT TO QTRALLOC 
READ 
CLOSE FORMAT 
ELSE 
SET FORMAT TO QTRALLOC 
CLEAR 


WAIT "ADDING NEW RECORD, Press Return to 
APPEND BLANK 
REPLACE FY WITH M FY 
REFLACE AFC WITH 11 AFC 
REPLACE QUAPTER WITH M QTR 
READ 
CLOSE FORMAT 
ENDIF 


ENDDO 


SET FILTEF TO 
CLOSE ALL 

SET CONFIFM OFF 
WAIT 

SET CONFIRM ON 


SE selectnum - 3 
DO FEMOVE INFORMATION 


More = .T. 
DO WHILE More 
CLEAF 
M APC * SPACE (4) 
8 6,0 TO 10,79 DOUBLE 
Q 7,10 SAY "Enter the APC Number of the Section 
to delete its 
allocation" GET M_APC PICTURE "1999" 
Q 8,10 SAY "or Press Return to QUIT" 
READ 


DENMPARE = * * 
More = E, 
LOOP 

ENDIF 


USE APC INDEX APC 
SEARCH* UPPER(M APC) 
LOCATE FOR APC=SEARCH 


IF FOUND () 
CLEAR 
@ 6,0 TO 9,79 DOUBLE 
@ 7,5 SAY "Section: "+SECTION 
@ 7,35 SAY "Section Code: "4S CODE 
& 8,5 SAY "Point of Contact:"4POC 
@ 8,35 SAY ; 
"Telephone: "+TRANSFORM(Telephone, " (999) 999-9999") 
ELSE 
CLEAR 


@ 6,0 TO 8,79 DOUBLE 
@ 7,5 SAY "APC requested is not in the Master 


Filo, > 
Please Try again.” 
7? CHR (7) 
e 15,0 
WAIT "Press Return to try again..." 
LOOP 
ENDIF 
M OTR = 0 
@ 14,0 TO 16,45 
Q 15,5 SAY "Enter the Quarter You Wish to Delete: 
De 
, 
GET M QTR PICTURE "9" 
READ 
USE QTRALLOC INDEX QTRALLOC 
SET FILTER TO FY=M FY .AND. QUARTER=M_QTR 
GO TOP 
LOCATE FOR APC=M_APC 
IF FOUND () 
CLEAR 
Maybe = " " 
SET FORMAT TO DELQALLO 
READ 
CLOSE FORMAT 
IF UPPER(Maybe) - "Y" 
DELETE 
ENDIF 
ELSE 
@ 20,0 CLEAR 
7? "Can't find the requested record" 
?? CHR(7) 
MAIT "Press any key to try again..." 
LOOP 
ENDIF 
ENDDO 


*-Give the user a chance to change their mind about 
deleting data 
YorN = " " 


CLEAR 
@ 5,1 SAY "Permanently remove records marked for 
deletion now? (Y/N) " GET YorN PICTURE 


wpn 
@ 7,1 SAY "(Process may take a few minutes to 
complete..)” 
READ 
IF YorN Y AA 
SET FILTER TO 
5,0 SAY "Please stand by while I reindex the 
firYé.." 
SET TALK ON 
REINDEX 
SET TALK OFF 
ELSE 
SET FILTER TO 
Nodels = O 
*--Count the number of records to be deleted 
? "Counting... Please wait." 
COUNT FOR DELETED() TO Nodels 


Permiss - "N" 
DO WHILE Permiss = "N" .AND. Nodels > 0 
CLEAR 


ER 


*Display all deleted records 
" 
DISPLAY APC, FY, QUARTER, ALLOCATION FOR 
DFLETEDP(! 
n 
Permiss e " " 
*-Give user all or some choice 
A 23,5 SAY "OK to delete all these? (Y/N) "; 
GET Permiss PICTURE "1" 
READ 
*--IF not OK to delete all, find out which 
IF Permiss $ "Y" 
RecNo s O 
Q 20,0 CLEAR 
*-Find Out which Records to recall 
@ 23,5 SAY "Recall which one (Record 
Number): ^"; 
GET RecNo PICTURE "999999" 
READ 
IF RecNo » O .AND. RecNo <# RECCOUNT () 
GOTO RecNo 
IF DELETED () 
RECALL 
Nodels = Nodels - I 
ENDIF 
ELSE 
@ 20,0 CLEAR 
@ 23,5 SAY "No such record: 
"+STR (RecNO, 4) 
? CHR (7) 
WAIT 
ENDIF 
ENDIF 
ENDDO (Permiss and No-dels) 
SET TALK ON 
CLEAR 
8 2,0 SAY TI? 
? 'PACKING DATABASE TO REMOVE RECORDS MARKED FOR 
DELETION' 
PACK 


ENDIF 

SET TALK OFF 
SET CONFIRM OFF 
WAIT 

SET CONFIRM ON 


CASE selectnum = 4 
* po REVIEW INFORMATION 


CLEAR 

M OTR = Q 

@ 6,0 TO 8,79 DOUBLE 

@ 7,15 SAY "Enter the Quarter to Review"; 
GET M QTR PICTURE "9" RANGE 1,4 


READ 
SET FILTER TO QUARTER-M QTR .AND. Fish EY 
*Display only those records user desires 
GO TOP 
BROWSE NOAPPEND NOMENU 
SET FILTER TO 
SET CONFIRM OFF 
WAIT 
SET CONFIRM ON 
ENDCASE 


ENDDO T 


RETURN 
* EOF: BMENU1.PRG 


* Program..: 
BMENU2 . PRG 


* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date.....: OF 14,89 


* Notice...: Copyright (c) 1989, ELBERT T. SHAW & JOAN 
ZIMMERMAN, All Rights Reserved 
* Notes....: 


SET TALK OFF 
SET BELL OFF 
SET ESCAPE OFF 
SET CONFIRM ON 


USE MOEXP 
CLEAR 
M FY = 0 


@6,0 to 8,79 DOUBLE 

@7,15 SAY "Enter the Fiscal Year for the Allocations:" : 
GET M FY PICTURE "99" 

READ 


DO WHILE .T. 
* ---Display menu options, centered on the screen. 
a diaw menu bor der: ond print heating 
CLEAR 


@ 2, O TO 14,79 DOUBLE 


e 3,8 
R E S] 


ab ab gb * 


SAY (UPDATE MONTHLY E XPENDITU 


@ 4,1 TO 4,78 DOUBLE 


---display detail lines 
7,25 SAY [1. ADD EXPENDITURES FOR FY ]4STR(M FY,2) 
8,25 SAY (2. CHANGE EXPENDITURES FOR FY ]4STR(M FY,2) 
9,25 SAY [3. REMOVE EXPENDITURES FROM FY ]*STR(M FY,2) 


10,25 SAY [4. REVIEW EXPENDITURES FOR FY ]4*STR(M FY,2) 


e 
8 12, 
STORE 


30 SAY “0. EXIT' 
O TO selectnum 


@ 14,33 SAY " select ny 
8 14,42 GET selectnum PICTURE "9" RANGE O,4 


READ 


DO CASE 
CASE selectnum = O 


CLEAR ALL 
CLOSE ALL 
RETURN 


CASE selectnum = 1 


* 


update 


"1999" 


DO ADD INFORMATION 
Adding = .T. 
DO WHILE Adding 
CLEAR 
M APC = SPACE (4) 
@ 6,0 TO 10,79 DOUBLE 
@ 7,10 SAY "Enter the APC of the Section to 
expenditures" GET M APC PICTURE 
@ 8,10 SAY “or Press Return to QUIT" 
READ 
TEAMSADE 1 OA 
Adding = .F. 
LOOP 
ENDIF 
USE APC INDEX APC 
SEARCH= UPPER (M_APC) 
LOCATE FOR APC=SEARCH 
IF FOUND () 
CLEAR 
@ 6,0 TO 9,79 DOUBLE 
@ 7,5 SAY "Section: "+SECTION 
@ 7,35 SAY "Section Code: "4S CODE 
8 8,5 SAY "Point of Contact:"4POC 
@ 8,35 SAY; 


"Telephone: "+TRANSFORM (Telephone, " (999) 999-9999") 


ELSE 
CLEAR 
@ 6,0 TO 8,79 DOUBLE 
@ 7,5 SAY "APC requested is not in the Master 


File, Please 


Change it 


Continue” 


Try again." 
?? CHR(7) 
@ 15,0 
WAIT "Press Return to try again..." 
LOOP 
ENDIF 


M_MONTR = 0 
8 14,0 TO 16,45 
@ 15,5 SAY "Enter the Month You Wish to Add: "; 
GET M MONTH PICTURE "99" RANGE 1,12 
READ i 
USE MOEXP INDEX MOEXP 
SET FILTER TO FY2M FY .AND. MONTH-M MONTH 
GO TOP E 
LOCATE FOR APC=M_APC 
IF FOUND () 
CLEAR. 
WAIT "RECORD ALREADY EXISTS, Press Return to 
Z SET FOPMAT TO MOEXP 
READ 
CLOSE FORMAT 
ELSE 
SET FORMAT TO MOEXP 
CLEAR 
WAIT "ADDING NEW RECORD, Press Return to 


APPEND BLANK 
REPLACE FY WITH M FY 
REPLACE APC WITH M APC 
REPLACE MONTH WITH M MONTH 
*--Replace Quarter based on Month entered 
DO CASE 
CASE M MONTH > 9 


REPLACE QUAPTER WITH 1 


file." 


CASE M MONTH > 6 
REPLACE QUAPTER WITH 4 


CASE M MONTH > 3 
FEELACE QUARTEP WITH 3 


CASE M MONTH »- 1 
REPLACE QUARTER WITH 2 
ENDCASE 
READ 
CLOSE FORMAT 
ENDIF 


ENDDO 
SET FILTER TO 
@ 5,0 SAY "Please stand by while I reindex the 


SET TALK ON 
REINDEX 

SET TALK OFF 
CLOSE ALL 

SET CONFIRM OFF 
WAIT 

BET CONFIRM ON 


CASE selectnum = 2 


* 


DO CHANGE INFORMATION 
Adding = .T. 
DO WBILE Adding 
CLEAR 
M APC = SPACE (4) 
@ 6,0 TO 10,79 DOUBLE 
@ 7,10 SAY "Enter the APC Number of the Section 


to update its expenditures" GET M APC PICTURE "!999" 


Q 8,10 SAY "or Press Return to QUIT" 
READ 


IF M APC - " " 
Adding - .F. 
LOOP 

ENDIF 


USE APC INDEX APC 
SEARCH= UPPER (M_APC) 
LOCATE FOR APC=SEARCH 


IF FOUND (} 
CLEAR 
@ 6,0 TO 9,79 DOUBLE 
@ 7,5 SAY "Section: "+SECTION 
@ 7,35 SAY "Section Code: "+S CODE 
@ 8,5 SAY "Point of Contact: "+POC 
8 8,35 SAY ; 
"Telephone: "+TRANSFORM (Telephone, " (999) 999-9999") 
ELSE 
CLEAR 


@ 6,0 TO 8,79 DOUBLE 
@ 7,5 SAY "APC requested is not in the Master 


File,; Please 
Try again." 
?? CHR(7) 
g 13,0 
WAIT "Press Return to try again...” 
LOOP 
ENDIF 
M MONTH - O 
@ 14,0 TO 16,45 
8 15,5 SAY "Enter the Month You Wish to Change: "; 
GET M MONTB PICTURE "99" RANGE 1,12 
READ 
USE MOEXP INDEX MOEXP 
SET FILTER TO FY-eM FY .AND. MONTH-M MONTH 
GO TOP 
LOCATE FOR APC=M_APC 
IF FOUND () 
CLEAR 
WAIT "RECORD ALREADY EXISTS, Press Return to 
Change it” SET FORMAT TO MOEXP 
READ 
CLOSE FORMAT 
ELSE 
SET FORMAT TO MOEXP 
CLEAR 
WAIT "ADDING NEW RECORD, Press Return to 
Continue” 
APPEND BLANK 
REPLACE FY WITH M FY 
REPLACE APC WITH M APC 
REPLACE MONTH WITH M MONTH 
*--Automatically Replace Quarter based on Month 
entered 


DO CASE 
CASE M MONTH » 9 
REPLACE QUAPTER WITH 1 


fils" 


to remove 


"3999" 


CASE M MONTH > 6 
REPLACE QUARTER WITH 4 


CASE M MONTH » 3 
REPLACE QUARTER WITH 3 


CASE M MONTH »- 1 
REPLACE QUARTER WITH 2 
ENDCASE 
READ 
CLOSE 
ENDIF 


FORMAT 


ENDDO 
SET FILTER TO 
Q 5,0 SAY "Please stand by while I reindex the 


SET TALK ON 
REINDEX 

SET TALK OFF 
CLOSE ALL 

SET CONFIRM OFF 
WAIT 

SET CONFIRM ON 


CASE selectnum = 3 


* 


DO REMOVE INFORMATION 
More * .T. 
DO WHILE More 
CLEAR 
M_APC = SPACE (4) 
@ 6,0 TO 10,79 DOUBLE 
@ 7,10 SAY "Enter the APC Number of the Section 
its 
expenditures” GET M APC PICTURE 


@ 8,10 SAY "or Press Return to QUIT" 
READ 


IF M_APC = a 
More e E, 
LOOP 

ENDIF 


USE APC INDEX APC 
SEARCH= UPPER(M AFC) 
LOCATE FOR APC=SEARCH 


IF FOUND () 
CLEAR 
@ 6,0 TO 9,79 DOUBLE 
@ 7,5 SAY "Section: "+SECTION 
@ 7,35 SAY "Section Code: "+S CODE 
8g 8,5 SAY "Point of Contact: "+P0C 
@ 8,35 SAY ; 
"Telephone: "+TRANSFORM (Telephone, " (999) 999-9999") 
ELSE 
CLEAR 


Filo, 


Q 6,0 TO 8,79 DOUBLE 
@ 7,5 SAY "APC requested is not in the Master 
Please 


Try again." 
7? CHR(7) 
@ 15,0 
WAIT "Press Return to try again...” 
LOOP 
ENDIF 


M_MONTH = 0 

@ 14,0 TO 16,45 

@ 15,5 SAY "Enter the MONTH You Wish to Delete: "; 
GET M_MONTH PICTURE "99" RANGE 1,12 


READ 
USE MOEXP INDEX MOEXP 
SET FILTER TO FY-M FY .AND. MONTH-M MONTH 
GO TOP 
LOCATE FOR APCeM APC 
IF FOUND () 

CLEAR 


Maybe = " ” 
SET FORMAT TO DELMOEXP 
READ 
CLOSE FORMAT 
IF UPPER (Maybe) = “y” 
DELETE 
ENDIF 
ELSE 
@ 20,0 CLEAR 
? "Can't find the requested record" 
?? CHR(?7) 
WAIT "Press any key to try again..." 
LOOP 
ENDIF 


ENDDO 


Z1 


YorN = " " 
CLEAR 
Q 5,1 SAY "Permanently remove records marked for 


deletion now? 


(YZNY ^; 
GET YorN PICTURE 
8 7,1 SAY "(Process may take a few minutes to 


nin 
` 


complete..)” 


READ 
IF YorN $ "Y" 
SET FILTER TO 
8 5,0 SAY "Please stand by while I reindex the 
filo." 
SET TALK ON 
REINDEX 
SET TALK OFF 
ELSE 
SET FILTER TO 
Nodels = 0 
*--Count the number of records to be deleted 
? "Counting... Please wait." 
COUNT FOR DELETED() TO Nodels 
Permiss - "N" 
DO WHILE Permiss = "N" .AND. Nodels » O 
CLEAR 
? 
DISPLAY APC, FY, MONTH, EXPENSES FOR DELETED () 
? 
Permiss = " " 
@ 23,5 SAY "OK to delete all these? (Y/N) "; 
GET Permiss PICTURE "ji" 
READ 
*--IF not OK to delete all, find out which 
IF Permiss € "Y" 
RecNo = O 
8 20,0 CLEAR 
8 23,5 SAY "Recall which one (Record 
Number): "; 
GET RecNo PICTURE "999999" 
READ 
IF RecNo > 0 .AND. RecNo <= RECCOUNT () 


GOTO RecNo 
IF DELETED () 
RECALL 
Nodels s Nodels - 1 
ENDIF 
ELSE 
@ 20,0 CLEAR 
@ 23,5 SAY “No such record: 


"+STR(RecNo, 4) 


C 


* 


ENDCASE 


ENDDO T 
RETURN 
* EOF: 
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* Progr 


? CHR(7) 
WAIT 
ENDIF 
ENDIF 
ENDDO (Permiss and No-dels) 
SET TALK ON 
CLEAR 
072.0. .SAr e 
? ‘PACKING DATABASE 
DELETION’ 
PACK 
SET TALK OFF 
SET CONFIRM OFF 
WAIT 
SET CONFIRM ON 


TO REMOVE RECORDS MARKED FOR 


ASE selectnum = 4 
DO REVIEW INFORMATION 
USE MOEXP INDEX MOEXP 
CLEAR 


M_MONTH = O 

@ 6,0 TO 8,79 DOUBLE 

@ 7,15 SAY "Enter the Month to Review"; 
GET M_MONTH PICTURE "99" RANGE 1,12 

READ 

*-Filter out extraneous information 

SET FILTER TO FYeM FY .AND. MONTHzM MONTH 

GO TOP 

BROWSE NOAPPEND NOMENU 

SET COMFTT11 OFF 

WAIT 

SET CONFIRM ON 


BMENU2.PRG 





am..: 


BMENU3.PRG 


* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 

Na A OS E RS 

* rtice...: Copyright (c) 1989, ELRERT T. SHAW & JOAN 
ZIMMERMAN, All Rights Reserved 


* Notes....! 


USE APC INDEX APC 
Ret =» CRR(17) +CAR(196)+CHR(217) 
DO WHILE .T. 


* ---Display menu options, centered on the screen. 
x draw menu border and print heading 
M_APC=SPACE (4) 

CLEAR 

@ 2, O TO 14,79 DOUBLE 


@ 3,12 SAY [U PDATE APC INFORMATION 
IGE) 
@ 4,1 TO 4,78 DOUBLE 
* ---display detail lines 
@ 7,30 SAY [1. ADD APC INFORMATION] 
@ 8,30 SAY [2. CHANGE APC INFORMATION] 
@ 9,30 SAY [3. REVIEW ALL APC INFORMATION] 
@ 16,22 SAY "[ APC is the Account Processing Code ]” 
@ 11, 30 SAY ’O. EXIT’ 
STORE O TO selectnum 


@ 14,33 SAY " select Z 
@ 14,42 GET selectnum PICTURE "9" RANGE 0,3 
READ 
DO CASE 
CASE selectnum = 0 

SET BELL ON 

SET TALK ON 

CLEAR ALL 

RETURN 


CASE selectnum = 1 
* DO ADD INFORMATION 
Adding = .T. 
DO WHILE Adding 
*---Ask for new APC to add 
CLEAR 
CLOSE FORMAT 
M_APC = SPACE (4) 
@ 6,0 TO 8,79 DOUBLE 
Q 7,15 SAY "Enter APC Code -> "; 
GET M_APC PICTURE "!999" 
8 15,15 SAY "Press Enter ["4Ret4") to return to 
Menu" 
READ 


*--Create lookup variable 
Search = UPFER(M_APC) 


*--If nothing entered, 
IF Search 9 " " 

EXIT 
ENDIF 


Leave Program 


*--See if APC is already Stored 
SEEK Search 


SET FORMAT TO APC 
*-—-If name Found Edit 
IF FOUND () 
CLEAR 
@ 6,0 TO 8,79 DOUBLE 
@ 7,15 


?? “APC Code selected is already in use, 
Please try again..." 
?? CHR(7) 
@ 22,0 
WAIT 
LOOP 
ENDIF 


*--If not found, Add new APC 
Ir .NOT. FOUND () 
APPEND BLANK 
REPLACE APC WITR M APC 
FEAD 
ENDIF 


ENDDO 

@ 5,0 SAY "Please stand by while I reindex the 
file.." 

SET TALK ON 

REINDEX 

SET TALK OFF 

LOOP 

CLOSE FORMAT 


E 
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CASE selectnum = 2 
* DO CHANGE INFORMATION 
CLEAR 
Adding = .T. 
DO WHILE Adding 
*---Ask for new APC to add 
CLEAR 
CLOSE FORMAT 
M_APC = SPACE (4) 
@ 6,0 TO 9,79 DOUBLE 
@ 7,15 SAY "Enter the APC Code you wish to 
change :"; 
GET M APC PICTURE "1999" 
@ 8,15 SAY "Press Enter ("*Ret*"] to return to 
Menu" 
READ 
*--Create lookup variable 
Search © OPPER(M_APC) 


*--If nothing entered, Leave Program 


IF Search z " " 
Adding = .F. 
LOOP 

ENDIF 


*--See if APC is already Stored 
SEEK Search 
SET FORMAT TO APC 


*--Tf name Found Edit 
IF FOUND () 
M_APCSTATUS = " ° 
CLEAR 
@ 6,0 TO 8,79 DOUBLE 
@ 7,15 SAY "Do You wish to put this APC Code 
into inactive 
status (Y/N):" GET M APCSTATUS 


PICTURE "J" 
READ 
*- IF WANT TO INACTIVATE APC, JUST PUT A 
INACTIVE 
CODE INTO FILE 
* ELSE EDIT TBE FILE AS USUAL. 
IF M APCSTATUS = "Y" 
REPLACE STATUS WITH I 
ELSE 
SET FORMAT TO APC 
READ 
CLOSE FORMAT 
ENDIF 
ELSE 
*--If not found, warn user 
@ 6,0 TO 8,79 DOUBLE 
(2 WyxE 
? "Can't Find the APC you requested: 
", Search 
?? CHR (7) 
WAIT 
ENDIF (found) 
ENDDO 
CLEAR 


@ 5,0 SAY "Please stand by while I reindex the 
file 

SET TALK ON 

REINDEX 

SET TALK OFF 

SET CONFIRM OFF 

WAIT 

SET CONFIRM ON 


CASE selectnum = 3 
* DO REVIEW INFORMATION 
SET HELP OFF 
GO TOP 
BROWSE NOAPPEND NOMENU 
SET CONFIRM OFF 
WAIT 
SET CONFTPM ON 


ENDCASE 
LOOP 
ENDDO 
RETURN 


* EOF: 
^2 


BMENU3. PRG 





* Program..: 


BMENU4 .PRG 


* Author...: ELBERT T. SRAM £ JOAN ZIMMERMAN 

* Do*e..... 02 14/89 

* Haotdeel..|; Copyright (c) 1989, ELBERT T. SHAW & JOAN 
ZIMMERMAN, ALL Rights Fererived 


* Notes....: 
* Reserved.: 
* 

SET TALK OFF 
SET BELL OFF 
SET ESCAPE OFF 
SET CGONFIRM ON 


selectnum 


DO MEIZE .T. 


* ——Display menu options, centered on the screen. 
draw menu border and print heading 
CLEAR 
2, 0 TO 14,79 DOUBLE 
3,28 SAY (PRINT 
4,1 TO 4,78 DOUBLE 
~—display detail lines 

7,33 SAY (1. MONTHLY REPORT} 

8,33 SAY (2. QUARTERLY REPORT] 

9,33 SAY (3. FISCAL YEAR PEPORT (RECAP)] 
10,33 SAY (4. PRINT GRAPHS] 
12, 33 SAY 'O. EXIT' 
STORE O TO selectnum 
8 14,33 SAY " select n 
8 14,42 GET selectnum PICTURE "9" RANGE 0,4 
READ 


REPORT S] 


«D aD (D D (D —* OG 0D 0D 


DO CASE 
CASE selectnum = O 
CLEAR ALL 
RETURN 


CASE selectnum = 1 
* DO MONTHLY REPORT 
DO BMENU4 1 
SET CONFIFM OFF 
WAIT 
SET CONFIRM ON 


CASE selectnum = 2 
* DO QUARTERLY REPORT 
DO BMENU4_2 
SET CONFIRM OFF 
WAIT 
SET CONFIRM ON 


CASE selectnum = 3 
* DO FY REPORT 
DO BMENU4 3 
SET CONFIRM OFF 


WAIT 
SET CONFIRM ON 


CASE selectnum = 4 
* DO PRINT GRAPAS 
DO BMENU4 4 
SET CONFIRM OFF 
MAIT 
SET CONFIRM ON 


ENDCASE 
ENDDO T 
RETURN 


* EOF: BMENU4.PRG 
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* Program..: 


BMENU4 1.PRG 
* Author...: ELBERT T. SHAW € JOAN ZIMMERMAN 
* Date.....3 02/14/89 
* Notice...: Copyright (c) 1989, ELBERT T. SHAW € JOAN 


ZIMMERMAN, All Rights Reserved 

* Notes.. 

SET TALE OFF 

SET BELL OFF 

SET ESCAFE OFF 

SET CONFIRM ON 

M FY = @ 

M MO = 0 

CLEAR 

@ 6, O TO 9,79 DOUBLE 

8 7,15 SAY "Enter the Fiscal Year for the report"; 
GET M FY PICTURE "99^" 
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READ 

@ 8,15 SAY "Enter the Month for the report"; 
GET M MO PICTURE "99" RANGE 1,12 

PEAD 


*** Restrict Output to selected FY and selected Month 
AR MONTHLY REPORT PRINTED HERE *** 


* EOF: BMENU4 1.PRG 
"A 


* Program..s 
BMENU4 2.PRG 


* Author... ELBERT T. SRAW & JOAN ZIMMERMAN 

* Date.....: 02/14/89 

* Notice...: Copyright (c) 1989, ELBERT T. SRAM £ JOAN 
ZIMMERMAN, All Rights Reserved 

* Notes....: 

SET TALK OFF 

SET BELL OFF 


SET ESCAPE OFF 
SET CONFIRM ON 
M FY-0 

M OTR = 0 

CLEAR 
e 6, o 
@ 7,15 


TO 9,79 DOUBLE 

SAY "Enter the Fiscal Year for the report"; 
GET M FI PICTURE "99" 

READ 

8 8,15 SAY "Enter the Quarter for the report"; 
GET M QTR PICTURE "9" RANGE 1,4 


READ 
*** OUARTEFLY REPORT FRINTED HEFE *** 


* EOF: BMENU4 1.PRG 
52 





* Program..: 


BMENO4 3.PRG 


* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date.....: 02/14/89 
* Notice...: Copyright (c) 1989, ELBERT T. SHAM & JOAN 


-ZIMMERMAN, All Rights Reserved 

ZaNotes- 

SET TALK OFF 

SET BELL OFF 

SET ESCAPE OFF 

SET CONFIRM ON 

M FY = 0 

* CLEAR THE SCREEN TO ACCEPT THE FY INPUT 

* DETERMINE THE FY OF THE REPORT 

CLEAR 

€ 6,0 TO 8,79 DOUBLE 

€ 7,15 SAY "Enter the Fiscal Year for the reports"; 
GET M_FY PICTURE "99" 


READ 
DO WHILE .T. 
* ---Display menu options, centered on the screen. 
E draw menu border and print heading 
CLEAR 
g 2, O TO 12,79 DOUBLE 


@ 3,8 SAY (FISCAL YEAR REPORTS) 
@ 4,1 TO 4,78 DOUBLE 

* ——--display detail lines 

8 7,33 SAY (1. FISCAL YEAR ALLOCATION REPORT] 

e 


8,33 SAY (2. FISCAL YEAR RECAP] 


@ 10, 33 SAY "o. EXIT’ 
STORE O TO selectnum 
8 12,33 SAY " select y 
@ 12,42 GET selectnum PICTURE "9" RANGE 0,2 
READ 
DO CASE 
CASE selectnum = 0 
SET BELL ON 
SET TALK ON 
CLEAR ALL 
RETURN 
CASE selectnum = 1 
* DO ALLOCATION 
kaa FY ALLOCATION REPORT PRINTED HERE 
kak 


SET CONFIRM OFF 
WAIT 


SET CONFIRM ON 


CASE selectnum = 2 
S po kXr EtiptT' ed 


*** PY RECAP REPORT PRINTED HERE *** 
SET CONFIRM OFF 


WAIT 

SET CONFIRM ON 
ENDCASE 
ENDDO T 
RETURN 
* EOF: BMENU4 3.PRG 
2 
* Program..: 

BMENU4 4.PRG 

* Author...: ELBERT T. SHAM & JOAN ZIMMERMAN 
* Date.....: 02/14/89 
* Notice...: Copyright (c) 1989, ELBERT T. SHAW € JOAN 


ZIMMERMAN, All Rights Reserved 
* Notes....? 

SET TALK OFF 

SET BELL OFF 

SET ESCAPE OFF 

SET CONFIRM ON 

M FY - 0 

M QTR - O 

M RANGE = 0 

DO WHILE .T. 


* ---Display menu options, centered on the screen. 
* draw menu border and print heading 

CLEAR 

€ 2, O TO 12,79 DOUBLE 


4,29 SAY [P RINT 
4,1 TO 4,78 DOUBLE 
~--display detail lines 


e GRAPH S] 

e 

* 

€ 7,24 SAY (1. PERCENT SPENT FOR QUARTER 
e 

e 


(BAR GRAPH)]) 
8,24 SAY [2. TREND GRAPHS (LINE GRAPH) ) 

10, 24 SAY 'O. EXIT' 
STORE O TO selectnum 
€ 12,33 SAY " select 
@ 12,42 GET selectnum PICTURE 
READ 


"n 


"9" RANGE 0,3 


DO CASE 
CASE selectnum = 0 
SET BELL ON 
SET TALK ON 
CLEAR ALL 
RETURN 


CASE selectnum = 1 
a DO PERCENT SPENT FOR QTF (BAR GRAPH) 
* Clear Screen for FY and QTR input 
CLEAR 
@6,0 to 9,79 DOUBLE 
@7,15 SAY "Enter the Fiscal Year of the 
Expenditure: "; 
GET M FY PICTURE "99" 
READ 
€ 8,15 SAY "Enter the Quarter to Review"; 
GET M QTR PICTURE "9" RANGE 1,4 
READ 


DETERMINE EXPENDITURE BY SECTION FOR EACH 
SECTION FOR THE QUARTER SELECTED, HIS FIGURE 
COULD BE A PARTIAL OUTLOOK FOR THE CURPENT 


QUARTER COMPARE TO CURRENT SECTION’S ALLOCATION 
AND DETERMINE PERCENTAGE SPENT 


*** PERCENT SPENT FOR QUAPTER GPAPH HFPE 


SET CONFIPM OFF 
WAIT 


READ 
SET CONFIRM ON 


CASE selectnum e 2 


* DO TREND (LINE GRAPH) 
M FY = 0 
* Clear Screen for FY input 
CLEAR 


@6,0 to 8,79 DOUBLE 
87,15 SAY "Enter the Fiscal Year of the Report:"; 
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GET M FY PICTURE "99" 
READ 


SECTION EXPENDITUFFS RY MONTH TO 
DEER EIERE TEL] 
MONTH OF FY. ALSO GRAPH TOTAL ALLOCATION FOR 
*** DEPARTMENT FOR EACH QUARTER. 
*** PRINT YEARLY TREND LINE GRAPH HERE 


eae TOTAL AVL 
Bal i 


* * X 
* DO LONG TERM TREND (TREND GRAPH) 
*** LOCATE ALL DATA FOR CURRENT FISCAL YEAR, AND 
PREVIOUS FISCAL YEARS UP TO TBE TWO YEARS 
FROM CURRENT YEAR 
*** TREND ON MONTHS EXPENDITURES, DISPLAY 
ALLOCATIONS FOR THOSE YEARS 
*** INDIVIDUAL APC EXPENDITURES ARE TOTALED TO GET 
A 
DEPARTMENT MIDE PICTURE 
*** PRINT LONG TERM TREND GRAPH HERE *** 
SET CONFIRM OFF 
WAIT 
SET CONFIRM ON 
ENDCASE 
ENDDO T 
RETURN 
* EOF: BMENUS.PRG 
“2 


APPENDIX D. 


TABLE OF PROGRAMS 

EMENU . PRG 

EMENU1.PRG 

EMENU1 2.PRG 
EMENUl 3.PRG 
EMENU2.PRG 

EMENU2 1.PRG 
EMENU2 2.PRG 
EMENU3.PRG 

EMENU3 1.PRG 
EMENU3 2.PRG 
EM3 2 1.PRG 
EMENU3 3.PRG 
EMENU3 4.PRG 
EM3 4 1.PRG 
EMENU3 5.PRG 
EMENU4.PRG 


DISCLAIMER 


The purpose of this programming code is to 
facilitate the understanding of the 
requirements presented in Chapter 5 of this 
thesis. The nature of this project precludes 
it actual implementation in DBASE III+. To 
fully implement the requirements the system 
designer will need a full range of capabilities 
that does not currently exist in DBASE III+. 

DBASE III+ served as the modeling tool by 
which the screens were generated and where 
necessary, specific code was written to 
illustrate a point. The actual working code 
merely acts as a shell in which to run the 
menus. A close analysis of the program code can 
facilitate implementation in a more suitable 
language, i.e., PARADOX, which can support the 
graphics and high level relationships involved 
in the various databases. Where the actual 
requirements process may appear to be unclear, 
comments were added within the code to explain 
these areas to the designer. 


* Program..: 


EMENU.PRG 
* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date.....: 02/16/89 
* Notice...: Copyright (c) 1989, All Rights Reserved 


GENEE e Mee 
SET TALK OFF 
SET BELL OFF 
SET STATUS OFF 
SET ESCAPE OFF 
SET CONFIRM ON 


DO WHILE .T. 


* -—--Display menu options, centered on the screen. 
: draw menu border and print heading 
CLEAR 


€ 2, O TO 14,79 DOUBLE 

Q 3,13 SAY (DEPARTMENT OF FAMILY PRACTICE PLANNED 
EQUIPMENT SYSTEM] 
4,1 TO 4,78 DOUBLE 
* ---display detail lines 
@ 7,27 SAY (1. UPDATE EQUIPMENT LISTING] 
@ 8,27 SAY [2. UPDATE PRIORITIES] 
@ 9,27 SAY [3. PRINT REPORTS] 
e 
e 


ap 


10,27 SAY [4. ARCHIVE HISTORICAL DATA] 
r227 SAY "0O. EXIT, 

STORE O TO selectnum 

@ 14,33 SAY " select " 
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EQUIPMENT PROGRAMS 


Q 14,42 GET selectnum PICTURE "9" RANGE 0,4 
READ 


DO CASE 
CASE selectnum e O 
SET BELL ON 
SET TALK ON 
CLEAR ALL 
RETURN 


CASE selectnum = 1 
* DO UPDATE EQUIPMENT LISTING 


DO EMENUI 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY ’Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 2 
* DO UFDPATE PRIORITIES 


DO EMENU2 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY “Press any key to continue...” GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 3 
* DO PRINT REPORTS 


DO EMENU3 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

8 23,0 SAY 'Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 4 
* DO ARCHIVE HISTORICAL DATA 


DO EMENU4 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY 'Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 
ENDCASE 


ENDDO T 

RETURN 

* EOF: EMENU.PRG 
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* Program..: 


EMENUI] .PRG 
* Buthor.,.: JOAN ZIMMERMAN & ELBERT SHAW 
* Date.....: 02/16/89 
* Notice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBERT 


SHAW, All Rights Reserved 


SET TALK OFF 
SET BELL OFF 
SET STATUS OFF 
SET ESCAPE OFF 
SET CONFIPM ON 
USE EQUIP 


DO WHILE .T. 


* ---Display menu options, centered on the screen. i= ES 
* draw menu border and print heading 

CLEAR 

8 2, O TO 14,79 DOUBLE 


& 3,17 SAY IU F DAT E PPOCUFEMENT Dos 


I N G] 


4,1 TO 4,78 DOUBLE 
---display detail lines 


» nm 


KP 


rogram..:; 
EMENUl 2.PRG 


€ 7,30 SAY [1. ADD EQUIPMENT INFORMATION] * Author...: JOAN ZIMMERMAN & ELBERT SHAM 
@ 8,30 SAY [2. CHANGE EQUIPMENT DATA] * Date.....: 02/16/89 
@ 9,30 SAY [3. REMOVE EQUIPMENT ENTRY) * Notice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBERT 
A 10,30 SAY [4, REVIEW EQUIPMENT LIST] SHAM, All Rights Reserved 
@ 12, 30 SAY ’0. EXIT’ SET TALK OFF 
STORE O TO selectnum SET BELL OFF 
A 14,33 SAY " select z SET STATUS OFF 
A 14,42 GET selectnum PICTURE "9" RANGE 0,4 SET ESCAPE OFF 
READ SET CONFIRM ON 
USE EQUIP 

DO CASE DO WHILE .T. 

CASE selectnum = 0 

RETURN * ---Display menu options, centered on the screen. 
* draw menu border and print heading 
CASE selectnum = 1 CLEAR 
* DO ADD INFORMATION a 2, O TO 12,79 DOUBLE 


SET CONFIRM OFF 


@ 3,23 SAY (CHANG E PROCUREMENT DAT A) 


SET FORMAT TO EMENU1_1 € 4,1 TO 4,78 DOUBLE 
APPEND BLANK * ---display detail lines 
*THIS COMPUTES THE EXTENDED PRICE @ 7,27 SAY [1. BY EQUIPMENT CODE NUMBER] 
REFLACE EXTPRICE WITH QTY * UNITFRICE @ 8,27 SAY (2. BY SECTION CODE] 
CLOSE FOPMAT @ 10, 27 SAY 'O. EXIT’ 
*VERIFY TBAT THE CODE NUMBER GIVEN IS NOT A STORE O TO selectnum 
DUPLICATE a 12,33 SAY " select T 
*IF IT IS, NOTIFY USER AND ALLOW THEM TO CHANGE THE A 12,42 GET selectnum PICTURE "9" RANGE 0,2 


*NUMBER MITROUT REEDITING THE COMPLETE INFORMATION 


READ 


*THEN REPLACE THE OLD CODE NUMBER WITH THE NEW 
we DO CASE 
STORE * * TO wait subst CASE selectnum = O 
@ 23,0 SAY "Press any key to continue...” GET RETURN 
wait subst 
READ CASE selectnum - 1 


SET CONFIPM ON 


CASE selectnum = 2 
* DO CHANGE INFORMATION 


DO EMENU1 2 


* DO BY EQUIPMENT CODE NUMBER 


CLEAR 

M_EQ = 0.0 

@6,0 TO 8,79 DOUBLE 

@ 7,15 SAY "Enter the Equipment Code Number:"; 
GET M EQ PICTURE "9999.99" 


READ 
SET CONFIRM OFF IF M EQ - O.0 
STOPE ' ' TO wait subst LOOP 
@ 23,0 SAY ‘Press any key to continue...’ GET ENDIF 
wait subst GO TOP 
READ LOCATE FOR EQCODE=M EQ 
SET CONFIRM ON SET FORMAT TO EMENU1_1 
READ 
CASE selectnum = 3 CLOSE FORMAT 
* DO REMOVE INFORMATION SET CONFIRM OFF 
STORE ' ' TO wait subst 
DO EMENU1_3 @ 23,0 SAY "Press any key to continue...’ GET 
SET TALK OFF wait subst 
SET CONFIRM OFF E READ 
STORE ' ' TO wait subst SET CONFIRM ON 
@ 23,0 SAY "Press any key to continue...” GET 
wait_subst CASE selectnum = 2 
READ * po BY SECTION CODE 
SET CONFIRM ON 
CLEAR 


CASE selectnum = 4 
* DO REVIEW INFORMATION 
M_SECT =" " 
CLEAR 
@ 6,0 TO 8,79 DOUBLE 
@ 7,15 SAY "Enter the section code of the section 


M SECT - " ” 
86,0 TO 8,79 DOUBLE 
87,15 SAY "Enter the Section Code for section 


needing changes:"; 


GET M SECT PICTURE "AAA" 


READ 
to review"; IF M SECT = " = 
GET M SECT PICTURE "XxX" LOOP 
READ ENDIF 
SET HELP OFF RECORD = " "n 
SET FILTER TO SECTCODE-M SECT GO TOP 
GO TOP CLEAR 


BROWSE NOAFPEND NOMENU 
SET FILTEF TO 

CLEAR MEMORY 

SET CONFIRM OFF 

STORE ' ' TO wait subst 


A 23,0 SAY “Press any key to continue...” GET 


wait subst 


READ 
SET CONFIRM ON 


LIST ALL EQCODE, SECTCODE, REQDATE, DESCFIFT, REQTYPE; 


FOR SECTCODE=M_SECT 
@21,10 SAY "Enter the Fecord Number of the record; 


to change:" GET RECORD 
READ 

GOTO ¿RECORD 

SET FORMAT TO EMENU1_1 


ENDCASE READ 
CLOSE FORMAT 
e SET CONFIFM OFF 
eer STORE * ’ TO wait subst 
uad Ern Er @ 23,0 SAY "Press any key to continue...’ GET 


wait subst 
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READ READ 





SET CONFIRM ON RECORD = P " 
ENDCASE GO TOP 
clear 
ENDDO T LIST ALL EQCODE,SECTCODRE,RFODATE,DESCRIPT,'FQTYt? : 
RETURN 
* EOF: EMENUl 2.PRG FOR SECTCODE=M_SECT 
22 821,10 SAY "Enter the Record Number of the record; 
O a EE 
READ 
GOTO RECORD 
* Program..: CLEAR 
EMENU] 3.PRG DISPLAY EQCODE, SRCTCODE, REQDATE, DESCRIPT, REOTYPE 
Á ? 
* Author...: JOAN ZIMMERMAN & ELBERT SHAW WAIT “REMOVE THIS RECORD? (Y/N)" TO ANSWER 
* Dato.....: 02/16/89 IF UPPER(ANSWER) «e "Y^" 
* Notice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBERT DELETE RECORD RECNO() 
SRAW, All Rights ENDIF 
SET TALK OFF SET TALK ON 
SET BELL OFF @ 7,15 
SET STATUS OFF RECALL ALL 
SET ESCAPE OFF WAIT "This is where the pack would go " 
SET CONFIRM ON SET TALK OFF 
USE EQUIP READ 
STILLATIT = .T. CLOSE FORMAT 
DO WHILE STILLATIT SET CONFIFM OFF 
STORE ' * TO wait subst 
* ---Display menu options, centered on the screen. € 23,0 SAY 'Press any key to continue...” GET 
* draw menu border and print heading wait subst 
CLEAR 
8 2, O TO 12,79 DOUBLE READ 
@ 3,17 SAY (REMOVE PROCUREMENT ENTR SET CONFIRM ON 
Y] ENDCASE 
@ 4,1 TO 4,78 DOUBLE 
* ---display detail lines ENDDO T 
@ 7,27 SAY (1. BY EQUIPMENT CODE NUMBER} RETURN 
€ 8,27 SAY [2. BY SECTION CODE) * EOF: EMENU1_2.PRG 
Mero, 27 SAY 'O. EXIT’ ^2 
STORE O TO selectnum 
8 12,33 SAY " select > 
@ 12,42 GET selectnum PICTURE "9" RANGE 0,2 
READ 
* Program..: 
DO CASE EMENU2 . PRG 
CASE selectnum = 0 
RETURN * Author...: JOAN ZIMMERMAN & ELPEFT SHAW 
* Date..... NOS B9 
CASE selectnum = 1 * Notice...: Copyright (c) 1989, JOAN ZIMMERMAN € ELBERT 
* DO BY EQUIPMENT CODE NUMBER SHAW, All Rights Reserved 
SET TALK OFF 
ANSWER e " " SET BELL OFF 
CLEAR SET STATUS OFF 
M EQ * 0.0 SET ESCAPE OFF 
86,0 TO 8,79 DOUBLE SET CONFIFM ON 
8 7,15 SAY "Enter the Equipment Code Number:"; USE EQUIP 
GET M EQ PICTURE "9999.99" DO WHILE .T. 
READ 
** If no number return to menu ** * ---Display menu options, centered on the screen. 
IF M EQ = 0.0 x draw menu border and print heading 
STILLATIT - .F. CLEAR 
LOOP @ 2, O TO 12,79 DOUBLE 
ENDIF 8 3,17 SAY [UP DA T E ERIORITIErES/ STATU 
** Look for equipment code ** Ss) 
LOCATE FOR EQCODE-M EQ g 4,1 TO 4,78 DOUBLE 
CLEAR * ---display detail lines 
DISPLAY EQCODE, SECTCODE, REQDATE, DESCRIPT, REQTYPE @ 7,32 SAY [1. UPDATE PRIORITIES} 
? @ 8,32 SAY [2. UPDATE STATUS} 
WAIT "REMOVE TAIS RECORD? (Y/N)" TO ANSWER @ 10, 32 SAY "Oo, EXIT’ 
IF UPPER(ANSWER) = "Y" STORE O TO selectnum 
DELETE RECORD RECNO () @ 12,33 SAY " select Ww 
ENDIF 8 12,42 GET selectnum PICTURE "9" RANGE 0,2 
SET TALK ON READ 
67,15 
RECALL ALL DO CASE 
MAIT "This is where the pack would go” CASE selectnum = 0 
SET TALK OFF RETURN 
SET CONFIRM OFF 
STORE ’ ' TO wait subst CASE selectnum = 1 
8 23,0 SAY 'Press any key to continue...' GET * TO "IPATF FPT^OFITIES 


wait subst 
DO KEMENU2 1 


READ 
SET CONFIRM ON SET CONFIRM OFF 
STOFE ' * TO wait subst 
CASE selectnum = 2 @ 23,0 SAY ‘Press any key to continue...’ GET 
* DO BY SECTION CODE wait subst 
READ 
ANSWER = " " SET CONFIFM ON 
CLEAR 
M_SECT = " S CASE selectnum = 2 
86,0 TO 8,79 DOUBLE * DO UPDATE STATUS 


87,15 SAY "Enter the Section Code for deletions:"; 
DO EMENU2 2 
GET M SECT PICTURE "8!AAA" 
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SET CONFIRM OFF 
STORE * ' TO wait subst 


@ 23,0 SAY 'Press nny key to continue...' GET 
wait subst 
READ 
SET CONFIRM ON 
ENDCASE 
ENDDO T 
RETURN 


* EOF: EMENU2. PRG 
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* Program..: 


EMENU2 1.PRG 


* Author...: JOAN ZIMMERMAN & ELBERT SHAW 

* Dato.....: 02/16/89 

* Notice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBERT 
SHAW, All Rights Reserved 


SET 
SET 
SET 
SET 
SET 
USE 


TALK OFF 
BELL OFF 
STATUS OFF 
ESCAPE OFF 
CONFIRM ON 
EQUIP 


DO WHILE .T. 


* 
* 


---Display menu options, centered on the screen. 
draw menu border and print heading 


CLEAR 


ODD DD gv (D (D (OD 


2, 0 TO 14,79 DOUBLE 
3,24 SAY [UP DAT E PRIORITIES) 
4,1 TO 4,78 DOUBLE 
---display detail lines 

7,31 SAY (1. MEDCASE EQUIPMENT] 

8,31 SAY (2. CEEP EQUIPMENT] 

9,31 SAY [3. CAPR EQUIPMENT] 
10,31 SAY [4. OTHER EQUIPMENT] 
37245 &Bb Ee "(s 3m" 


STORE O TO selectnum 


e 
e 


14,33 SAY " select z 
14,42 GET selectnum PICTURE "9" RANGE 0,4 


READ 


DO CASE 


CASE selectnum = 0 
RETURN 


CASE selectnum = 1 

* DO MEDCASE EQUIPMENT 
CLEAR 
SET FILTER TO REOTYPE="MEDC" 
GO TOP 


BROWSE FIELDS 
EQCODE, REQTYPE, SECTCODE, DESCRIPT,URGCODE, PRIORITY, 


QTY, UNITPRICE 
SET FILTER TO 
SET CONFIRM OFF 
STORE ' ' TO wait subst 
€ 23,0 SAY 'Press any key to continue...' GET 


wait subst 


READ 
SET CONFIRM ON 


CASE selectnum = 2 
* DO CEEP EQUIPMENT 


CLEAR 

SET FILTER TO REQTYPE="CEEP" 

GO TOP 

BROWSE FIELDS 

EQCODE, REQTYPE, SECTCODE, DESCRIPT, URGCODE, 
PRIORITY, OTY, UNITPRICE 

SET FILTER TO 


SET CONFIRM OFF 
STORE * ' TO wait subst 
€ 23,0 SAY 'Press any key to continue...' GET 


wait subst 


READ 
SET CONFIRM ON 


CASE selectnum » 3 
* DO CAPR EQUIPMENT 


CLEAR 

SET FILTER TO REQTYPE="CAPR" 
GO TOP 

BROWSE FIELDS 


EQCODE, REQTYPE, SECTCODE, DESCRIPT, URGCODE, 
PRIORITY, OTY, UNITPRICE 
SET FILTER TO 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 4 
* pO OTHER EQUIPMENT 


CLEAR 

SET FILTER TO REQTYPE-S"OTHE" 

GO TOP 

BROMSE FIELDS 

EQCODE, REQTYPE, SECTCODE,DESCRIPT, URGCODE, 
PRIORITY, OTY, ONITPRICE 

SET FILTER TO 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

8 23,0 SAY 'Press any key to continue...' GET 
wait subst 

READ 

SET CONFIRM ON 
ENDCASE 


ENDDO T 

RETURN 

* EOF: EMENU2.PRG 
“E 





* Program..: 


EMENU2 2.PRG 


* Author...: JOAN ZIMMERMAN & ELBERT SHAW 

* Date. Da DIES 

* Notice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBERT 
SHAW, All Rights reserved 

SET TALK OFF 

SET BELL OFF 

SET STATUS OFF 

SET ESCAPE OFF 

SET CONFIRM ON 

USE EQUIP 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
* draw menu border and print heading 

CLEAR 

& 2, 0 TO 12,79 DOUBLE 

@ 3,28 SAY [UP DATE STATUS) 

€ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

e 7,31 SAY [1. BY EQUIPMENT CODE) 

8 8,31 SAY [2. BY SECTION CODE] 

@ 10, 31 SAY ’0. EXIT’ 


STORE O TO selectnum 

8 12,33 SAY " select n 

€ 12,42 GET selectnum PICTURE "9" RANGE 0,2 
READ 


DO CASE 
CASE selectnum = O 
RETURN 


CASE selectnum = 1 
* po BY EQUIPMENT CODE 


CLEAR 
M EQ = 0.0 
86,0 TO 2,79 DOUBLE 
e 7,195 SAY "Enter the Equipment Code Number:"; 
GETSDOEQ PICTUEE C 905959 
READ 
IF M_ EQ = 0.0 
LOOP 
ENDIF 
GO TOF 
LOCATE FOR EQCODE-M EQ 
SET FORMAT TO EMENU2 2 
READ 
CLOSE FORMAT 
SET CONFIRM OFF 
STORE ' ' TO wait subst 
€ 23,0 SAY “Press any key to continue...” GET 
wait subst 
READ 


SET CONFIRM ON 


CASE selectnum = 2 
SEDC BY SETITI CDE 


CLEAR 
HESRCT 2" " 
6,0 TO 8,79 DOUBLE 
87,15 SAY "Enter the Section Code for STATUS 
updates:"; 
GET M SECT PICTURE "AAA" 
READ 
ifm sECT =" * 
LOOP 
ENDIF 
RECOPD s» " 5 
GO TOP 
CLEAR 
LIST ALL 
EQCODE,SECTCODE,REQDATE,DESCRIPT, REQTYPE, STATUS; 
FOR SECTCODEsM SECT 
21,10 SAY "Enter the Record Number for STATUS 


updates: "; 


READ 

GOTO &RECORD 

SET FORMAT TO EMENU2 2 
READ 

CLOSE FORMAT 


GET RECORD 


SET CONFIFM OFF 
STORE ' ' TO walt subst 


€ 23,0 SAY “Press any key to continue...’ GET 
wait subst 
READ 
SET CONFIRM ON 
ENDIASE 
ENIDO T 
RETOFN 
* ef: EMENU2 2.PRG 
nz 





* Program..: 


EMENU3.PRG 


* Mthor...: JOAN ZIMMERMAN & ELBERT SHAW 

* Inte.....3 02/16/89 

* fotice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBERT 
SHM, All Rights Reserved 

SET TALK OFF 

SET BELL OFF 

SET STATUS OFF 

SET ESCAPE OFF 

SET CONFIRM ON 


DO@HILE .T. 


* ---Display menu options, centered on the screen. 
* draw menu border and print heading 
TLEAR 

YX 2, O TO 15,79 DOUBLE 

& 3,28 SAY [P R INT REPORTS] 

& 4,2 TO 4,78 DOUBLE 

* ---display detail lines 

*& 7,27 SAY [1. DEPAFTMENT REPORTS] 

8 8,27 SAY [2. EQUIPMENT TYFE FEPORTS] 

& 9,27 SAY [3. PRIORITY WORKSHEETS] 

Y 10,27 SAY (4. HISTORICAL FILE REPORTS] 

$ 11,27 SAY (5. EXPORT FILES TO SPREADSHEET] 
Meio, 27 SAY *0. EXIT” 


3TORE O TO selectnum 

& 15,33 SAY " select u 

4 15,42 GET selectnum PICTURE "9" RANGE 0,5 
READ 


DO CASE 
CASE selectnum - O 
RETURN 


CASE selectnum - 1 
* DO DEPARTMENT REPORTS 


DO EMENU3 1 


SET CONFIRM OFF 

STORE ’ ' TO wait subst 

@ 23,0 SAY 'Press any key to continue...' GET 
wai. subst 

READ 

SET CONFIRM ON 
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CASE selectnum = 2 


DO CATEGORY/STATUS PEPORTS 
DO EMENU3_2 
SET CONFIRM OFF 


STORE ' ' TO wait subst 

8 23,0 SAY 'Press any key to continue...’ GET 
wait subst 

READ 


SET CONFIRM ON 


CASE selectnum = 3 


* 


DO PRIORITY WORKSHEET REPORT 


DO EMENU3 3 

SET CONFIRM OFF 

STORE ' ' TO wait subst 

8 23,0 SAY 'Press any key to continue...' GET 


wait subst 


READ 
SET CONFIRM ON 


CASE selectnum = 4 


* 


DO HISTORICAL FILE REPORTS 
DO EMENUS 4 


SET CONFIRM OFF 


STORE ' ’ TO wait subst 

€ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 

READ 


SET CONFIRM ON 


CASE selectnum = 5 


* 


DO EXPORT TO FILE 
DO EMENU3_5 


SET CONFIRM OFF 
STORE ’ ’ TO wait subst 


@ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 
READ 
SET CONFIRM ON 
ENDCASE 
ENDDO T 
RETURN 
* EOF: EMENU3.PRG 
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* Program..: 


EMENU3 1.PRG 


* Author...: JOAN ZIMMERMAN & ELBEPT SHAW 

* Date.....: 02/17/89 

* WHotice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBEPT 
SHAW, All Rights Reserved 


SET TALK OFF 
SET BELL OFF 
SET STATUS OFF 
SET ESCAPE OFF 
SET CONFIRM ON 
USE EQUIP 


DO WHILE 


"T. 


* -—-Display menu options, centered on the screen. 


* 


CLEAR 
2, 
3,23 SAY [DEPARTMENT REPORTS) 
4,1 TO 4,78 DOUBLE 

---display detail lines 


e 
e 
a 
* 
e 


e 
e 
a 


draw menu border and print heading 


O TO 13,79 DOUBLE 


7,32 SAY [1. BY COST] 
8,32 SAY [2. BY URGENCY] 
9,32 SAY [3. BY STATUS CODE] 


1315 


32 SAY 'O. EXIT’ 


STORE O TO selectnum 
8 13,33 SAY " select " 
Q 13,42 GET selectnum PICTURE "9" RANGE 0,3 


READ 


DO CASE 
CASE selectnum = O 


f fedes d 


RETURN 


CASE selectnum = 1 


* 


DO BY COST 


*"**** Bet index to cost sort and Print report here 


SET CONFIRM OFF 


STOFE ' ' TO wait subst 

@ 23,0 SAY 'Press any key to continue...’ GET 
walt_subst 

READ 


SET CONFIRM ON 


CASE selectnum = 2 
* DO BY URGENCY 


**** Bet index to urgency sort, print report 


here **^*** 


wait 


SET CONFIRM OFF 

STORE ' * TO wait subst 

@ 23,0 SAY 'Press any key to continue...” GET 
_subst 

READ 

SET CONFIRM ON 


CASE selectnum = 3 
* po BY STATUS CODE 


***** Bet index to status code sort, print report 


here ***t*t* 


wait 


SET CONFIRM OFF 

STORE ' ’ TO wait subst 

@ 23,0 SAY ‘Press any key to continue...’ GET 
_subst 

READ 

SET CONFIRM ON 


ENDCASE 


ENDDO T 
RETURN 
* EOF: EMENU3_1.PRG 
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* Pr 





Ogram..: 


EMENU3 2.PRG 


* Author...: JOAN ZIMMERMAN & ELBERT SHAW 


* Da 


te... ..: 02/17/89 


* Notice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBERT 


SHAW 
* Re 
SET 
SET 
SET 
SET 
SET 
USE 


DO W 


* 
* 


C 


PEED 0D o— (05 05 


, All Rights 
served 

TALK OFF 
BELL OFF 
STATUS OFF 
ESCAPE OFF 
CONFIRM ON 
EQUIP 


HILE .T. 


---Display menu options, centered on the screen. 
draw menu border and print heading 
LEAR 
2, 0 TO 14,79 DOUBLE 
3,15 SAY [P R OC UR EME ON T T Y PE REPOR 


4,1 TO 4,78 DOUBLE 
---display detail lines 
7,32 SAY [1. MEDCASE EQUIPMENT) 
8,32 SAY [2. CEEP EQUIPMENT) 
9,32 SAY [3. CAPR EQUIPMENT) 
10,32 SAY [4. OTRER] 
12, 32 SAY 'O. EXIT' 


STORE O TO selectnum 


e 
e 


14,33 SAY " select E 
14,42 GET selectnum PICTURE "9" RANGE 0,4 


READ 


DO CASE 


CASE selectnum = O 
RETURN 


CASE selectnum = 1 

* DO MEDCASE EQUIPMENT 

* Call Sorting program, sort by priority or cost * 
DO EM3 2 1 

***** Print MEDCASE Equipment report here ***** 


SET CONFIRM OFF 


2006 


STORE ' ' TO wait subst 
€ 23,0 SAY 'Press any key to continue...’ GPT 
wait subst 


READ 
SET CONFIRM Of 


CASE selectnum = 2 
* DO CEEP EQUI£MENT 


* Call Sorting program, sort by priority or cost * 
DO EM3 2 1 


***** Print CEFS Nuguipment report here ***** 


SET CONFIRM CFF 

STORE * * TO wait_subst 

@ 23,0 SAY 'Frezs any key to continue...” GET 
wait_subst 


READ 
SET CONFIRM ON 


CASE selectnum = 3 
* DO CAPR EQUIPMENT 


* Call Sorting program, sort by priority or cost * 
DO EM3 2 1 


***** Print CAPR Equipment report here ***** 


SET CONFIRM CZF 

STORE ' ' TO weit subst 

8 23,0 SAY “Press any key to continue...’ GET 
walt_subst 


READ 
SET CONFIRM OM 


CASE selectnum = 4 
* DO OTHER 


* Call Sorting program, sort by priority or cost * 
DO EM3 2 1 


***** Print OTHER Equipment report here ***** 


SET CONFIRM OF 

STORE ’ * TO wait subst 

8 23,0 SAY 'Press any key to continue...” GET 
wait subst 


READ 
SET CONFIRM ON 
ENDCASE 
ENDDO T 
RETURN 
* EOF: EMENU3_2.PRG 
aZ 





* Program..: 


EM3 2 1.PRG 


* Author...: JOAN ZIMMERMAN € ELBERT SHAN 
* Date.....: 02/17/89 

* Notice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBERT 
SHAM, All Rights Reserved 

SET TALK OFF 

SET BELL OFF 

SET STATUS OFF 

SET ESCAPE OFF 

SET CONFIRM ON 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
z draw menu border and print heading 
CLEAR 


@ 2, 0 TO 12,79 DOUBLE 

Cs ISESAYEITEHEOSOSSSE DIETS TIR ESD SORT OPT 
I O N} 

@ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

@ 7,33 SAY [1. SORT BY FPFIORITY) 

@ 8,33 SAY [2. SORT BY COST] 

8 10, 73345SAY "DO: EXTT' 

STORE O TO selectnum 

8 12,33 SAY " select " 


@ 12,42 GET selectnum PICTURE "9" RANGE 0,2 SET CONFIRM ON 


READ 
CASE selectnum = 2 
DO CASE c DO CREF FPTOPITY FORM 
CASE selectnum = O 
RETURN * REPORT FORM EM3 3 ALL FOR REQTYPESCERP TO PRINT 
CASE selectnum = 1 
* DO SORT BY PRIORITY SET CONFIRM OFF 
STORE ’ ’ TO wait subst 
****** Bet indexes here to sort by priority ***** 8 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 
READ 


SET CONFIRM ON 
SET CONFIRM OFF 


STORE * ' TO wait subst CASE selectnum = 3 
8 23,0 SAY ‘Press any key to continue...’ GET * DO CAPR PRIORITY FORM 
wait subst 
READ * REPORT FORM EMS 3 ALL FOR REQTYPESCAPR TO PRINT 
RETURN 
SET CONFIRM OFF 
CASE selectnum - 2 STORE ' ' TO wait subst 
* DO SORT BY COST @ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 
READ 
***** Set indexes here to sort by cost ***** SET CONFIRM ON 


CASE selectnum = 4 
* pO OTHER PRIORITY FORM 
SET CONFIRM OFF 





STORE ' ' TO walt subst * REPORT FORM EM3 3 ALL FOR REQTYPESOTHE TO PRINT 
f 23,0 SAY “Press any key to continue...” GET 
wait subst SET CONFIRM OFF 
READ STORE ' ' TO wait subst 
RETURN 8 23,0 SAY 'Press any key to continue...' GET 
ENDCASE wait subst 
READ 
ENDDO T SET CONFIRM ON 
RETURN ENDCASE 
* EOF: EM3 2 1.PRG 
^Z ENDDO T 
RETURN 
* EOF: EMENU3 3.PRG 
SZ 


* Program..: 





EMENU3 3.PRG 
* Author...: JOAN ZIMMERMAN & ELBERT SHAW * Program..: 
* Date.....? 02/17/89 EMENUI_4.PRO 
* Notice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBEPT 
SHAW, All Rights Reserved * Author...: JOAN ZIMMERMAN & ELBERT SHAW 
SET TALK OFF * patQ.....: 02/11/89 
SET BELL OFF * Notice...: Copyright (c) 1989, JOAN ZIMMEPMAN & ELBERT 
SET STATUS OFF SHAW, All Rights Reserved 
SET ESCAPE OFF SET TALK OFF 
SET CONFIRM ON SET BELL OFF 
USE EQUIP SET STATUS OFF 
SET ESCAPE OFF 
***** Set cost sort, highest to lowest ***** SET CONFIRM ON 
DO MHILE .T. USE EQHIST 
* ---Display menu options, centered on the screen. DO WHILE .T. 
E draw menu border and print heading 
CLEAR * ---Display menu options, centered on the screen. 
8 2, O TO 14,79 DOUBLE * draw menu border and print heading 
@ 3,17 SAY [PRIORITY WORKSHEET FORM CLEAR 
S) @ 2, O TO 12,79 DOUBLE 
8 4,1 TO 4,78 DOUBLE @ 3,23 SAY (HISTORICAL REPORT S) 
* --—display detail lines Q 4,1 TO 4,78 DOUBLE 
8 37,29 SAY [1. MEDCASE PRIORITY FORM] * ---display detail lines 
Q 8,29 SAY [2. CEEP PRIORITY FORM) H 37,27 SAY [1. PRINT HISTORICAL DATA REPOPTS] 
8 9,29 SAY [3. CAPR PRIORITY FORM] € 8,27 SAY [2. PRINT HISTORICAL SUMMARY] 
Q 10,29 SAY [4. OTHER PRIORITY FORM) @ 10, 27 SAY “0. EXIT” 
Biz, 29 SAY ’O. EXIT’ STORE 0 TO selectnun 
STORE O TO selectnum @ 12,33 SAY ” select S 
Q 14,33 SAY " select e € 12,42 GET selectnum PICTURE "9" RANGE 0,2 
8 14,42 GET selectnum PICTURE "9" RANGE 0,4 READ 
READ 
DO CASE 
DO CASE CASE relecthum = O 
CASE selectnum = 0 RETURN 
RETURN 
CASE selectnum = 1 
CASE selectnum = 1 * DO PRINT ALL HISTORICAL DATA 
* DO MEDCASE PRIORITY FORM DO EM3 4 1 
* REPORT FORM EMO 3 FOR REQTYPE-MEDC TO PRINT SET CONFIRM OFF 
STORE ' ' TO wait subst 
8 23,0 SAY 'Press any key to continue...' GET 
SET CONFIRM OFF wait subst 
STORE ' ' TO wait subst READ 
8 23,0 SAY 'Press any key to continue...' GET SET CONFIPM ON 
wait subst 
READ CASE selectnum = 2 


20] 


* DO PRINT HISTORICAL SUMMARY 


* THE RISTORICAL SUMMARY ROUTINE TAKES THE RISTOFICAL 
F1LY 


* AND COMPUTES THE FOLLOWING INFORMATION 

* THE TOTAL NUMBER OF REQUESTS BY TYFE 

a THE AVERAGE COST PER TYPE 

e THE AVERAGE TIME TO COMPLETE THE ACTION BASED 
ON THE 

z DURATION INFORMATION COMPUTED UPON ARCHIVING 

* TRE NUMBER OF REQUESTS BY SECTION, THEN TYPE 

* THE AVERAGE COST BY SECTION, THEN TYPE 


* PRINT HISTORICAL SUMMARY REPORT HERE 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY ‘Press any key to continue...’ 
wait subst 

READ 

SET CONFIRM ON 


GET 


ENDCASE 


ENDDO T 

RETURN 

* EOF: EMENU3_4.PRG 
^L 


* Program..: 
EM3_4_1.PRG 
* Author...: JOAN ZIMMERMAN & ELBERT SHAW 
* Date.....: 02/17/89 
* Notice...: Copyright (c) 
SHAW, All Rights 
* Reserved 
SET TALK OFF 
SET BELL OFF 
SET STATUS OFF 
SET ESCAPE OFF 
SET CONFIRM ON 


1969, JOAN ZIMMERMAN & ELBERT 


* Get desired earliest month of report 
CLEAR 
M DATE = " 5 
86,0 TO 8,79 DOUBLE 
@ 7,10 SAY “Enter the earliest Month and Year for historical 
report: "; 
GET M DATE PICTURE "XX/XX" 

READ 
IF M DATE * " " 

LOOP 
ENDIF 
DO WRILE .T. 


* ---Display menu options, centered on the screen. 
* draw menu border and print heading 

CLEAR 

e 2, O TO 13,79 DOUBLE 


8 3,23 SAY [HI STORICAL REPORT 8 
@ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

€ 7,33 SAY (1. BY SECTION) 

@ 8,33 SAY (2. BY EQUIPMENT TYPE) 

& 11, 33 SAY ‘0. EXIT’ 

STORE O TO selectnum 

8 13,33 SAY " select 2 

8 13,42 GET selectnum PICTURE "9" RANGE 0,2 

READ 


DO CASE 
CASE selectnum = O 
RETURN 


CASE selectnum - 1 
* DO BY SECTION 


***** Set indexes here for sections **5*** 


***** Print Historical report by Section here ***** 


SET CONFIRM OFF 


STORE ' * TO wait subst 

€ 23,0 SAY 'Press any key to continue...’ GET 
wait subst 

READ 


SET CONFIRM ON 


CASE selectnum = 2 
* DO BY CATEGORY 
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Set indexes here for Equipment type ***** 


***** Print Historical report by Equipment Type hare 


LESES 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

€ 23,0 SAY ‘Press any key to continue...’ 
wait subst 


GET 


READ 
SET CONFIRM ON 
ENDCASE 
ENDDO T 
RETURN 
* EOF: EM3 4 1.PRG 
^g 


* Program..: 
EMENU3_S.PRG 


* Author... .: 
* Date.....: 02/17/89 

* Notice...: Copyright (c) 1989, 
SHAW, All Rights Raserved 

SET TALK OFF 

SET BELL OFF 

SET STATUS OFF 

SET ESCAPE OFF 

SET CONFIRM ON 


JOAN ZIMMERMAN & ELBERT SHAW 


JOAN ZIMMERMAN & ELBERT 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
z draw menu border and print heading 

CLEAR 

@ 2, O TO 12,79 DOUBLE 


Q 3,14 SAY (E X P OR T E IES TO SPREADS 
H E E T) 

8e 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

e 37,26 SAY [1. EXPORT CURRENT DATABASE] 

e 8,26 SAY [2. EXPORT HISTORICAL DATABASE] 

e 10, 26 SAY 'O. EXIT’ 

STORE O TO selectnum 

8 12,33 SAY " select hy 

@ 12,42 GET selectnum PICTURE "9" RANGE 0,2 


READ 
DO CASE 
CASE selectnum = O 
RETURN 


CASP selectnum = 1 
* DO EXPORT CURRENT DATABASE 


USE EQUIP 


AAÑARA 


Write CURRENT DATABASE export program here 


ARANA 


CLOSE ALL 


SET CONFIRM OFF 


STORE * ° TO wait subst 

@ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 

READ 


SET CONFIRM ON 


CASE selectnum - 2 
* DO EXPORT RISTORICAL DATABASE 


USE EQHIST 


anne 
here ***** 


Write HISTORICAL DATABASE export program 


CLOSE ALL 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

€ 23,0 SAY 'Press any key to continue...” 
wait subst 

READ 

SET CONFIRM ON 


GET 


ENDCASE 


ENDDO T 
RETURN 


* EOF: EMENU3 5.PRG 
A 
2 


* Program..: 
EXENU4.PRG 


* Author...: JOAN ZIMMERMAN & ELBERT SAAW 

* Date.....: 02/16/89 

* Notice...: Copyright (c) 1989, JOAN ZIMMERMAN & ELBERT 
SHAW, All Rights Reserved 

* Notes....: 


* 


SET TALK OFF 
SET BELL OFF 
SET STATUS OFF 
SET ESCAPE OFF 
SET CONFIRM ON 


* ---Display menu options, centered on the screen. 
» draw menu border and print heading 
CLEAR 


ANSWER = " " 

8 4, O TO 16,79 DOUBLE 

8 5,175 SAY (ARCHIVE TRO HISTORICAL F 
I L E] 

@ 6,1 TO 6,78 DOUBLE 

@ 8,15 SAY "CAUTION: All files with a received status, 
RC, will be" 

8 9,25 SAY "removed from the equipment listing" 

@ 10,25 SAY "to the historical file." 

8 14,25 SAY "Do you wish to continue the archive? (Y/N)"; 


GET ANSWER PICTURE "!A" 
READ 
IF ARSWER $ "Y" 
RETURN 
ELSE 
@ 18,15 SAY "**** Program to Archive file ****” 
* THE PROGRAM SEARCHES THE ACTIVE FILE FOR STATUS 
CODES = RC 
* IF FOUND IT TRANSFERS THE NECESSARY FIELDS TO THE 
BISTORICAL 
* FILE AND COMPUTES THE DURATION IN DAYS BETWEEN THE 
REQUEST 
* DATE AND CURRENT SYSTEM DATE. THE SYSTEM DATE IS 
ALSO INSERTED 
* INTO TBE HISTORICAL DATABASE RECORD ALON WITH THE 
COMPUTED 
* DURATION. 
ENDIF 
WAIT "Press any key to continue ..." 
SET STATUS ON 
SET TALK ON 
CLEAR ALL 
RETURN 


RETURN 
* EOF: EMENU4. PRG 
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APPENDIX E. 


TABLE OF PROGRAMS 


PMENU . PRG 
PMENU] . PRG 
PMENU2 . PRG 
PMENU3.PRG 
PMENU4 . PRG 
PMENU4 1.PRG 
PMENU4 2.PRG 
PMENU4 3.PRG 
PMENU4 4.FRG 
PMENUS.PRG 
PMENU6 . PRG 


DISCLAIMER 


The purpose of this programming code is to 
facilitate the understanding of the 
requirements presented in Chapter 5 of this 
thesis. The nature of this project precludes 
it actual implementation in DBASE III+. To 
fully implement the requirements the system 
designer will need a full range of capabilities 
that does not currently exist in DBASE III+. 

DBASE III+ served as the modeling tool by 
which the screens were generated and where 
necessary, specific code was written to 
illustrate a point. The actual working code 
merely acts as a shell in which to run the 
menus. A close analysis of the program code can 
facilitate implementation in a more suitable 
language, i.e., PARADOX, which can support the 
graphics and high level relationships involved 
in the various databases. Where the actual 
requirements process may appear to be unclear, 
comments were added within the code to explain 
these areas to the designer. 


* Program: 


PMENU.PRG 
* Author.: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date...: 02/02/89 
* Notice.: Copyright (c)1989, E. T. SHAW & JOAN ZIMMEFMAN,Al11 
Rights Reserved * Notes....:Main Menu for the Personnel 
System 


SET TALK OFF 
SET BELL OFF 
SET ESCAPE OFF 
SET CONFIRM ON 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
E draw menu border and print heading 

CLEAP 

@ 2, O TO 16,79 DOUBLE 


€ 3,15 SAY [DEPAPTMENT OF FAMILY PPACTICE PEPSONNEL 
SYSTEM] 


@ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

@ 7,22 SAY [1. Update Personnel Listing] 

@ 8,22 SAY [2. Update TDA Listing] 

e 9,22 SAY [3. Quick Update from RIR Peport] 

€ 10,22 SAY [4. Update CME Listing/Budget] 

€ 11,22 SAY [5. Update Leave and Absence Listings] 
€ 12,22 SAY [6. Print Reports] 

814, 22 SAY [O..FXIT] 


selectnum = O 

@ 16,33 SAY " select " 

€ 16,42 GET selectnum PICTUPE "9" RANGE 0,6 
READ 


DO CASE 
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CASE selectnum = O 
CLEAR ALL 
RETURN 


CASE selectnum = 1 
* DO Update Personnel Listing 


DO PMENU1 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 2 
* DO Update TDA Listing 


DO PMENU2 


SET CONFIRM OFF 

STORE * * TO wait_subst 

@ 23,0 SAY ‘Press any key to continue...’ 
wait subst 

READ 

SET CONFIRM ON 


GET 


CASE selectnum = 3 
* DO Quick Update from PIR Report 


DO PMENU3 


SET CONFIRM OFF 

STOPE * ' TO wait subst 

@ 23,0 SAY ‘Press any key to continue...’ 
wait subst 

RÉAD 

SET CONFIRM ON 


GET 


CASE selectnum = 4 
* DO Update CME Listing/Budget 


DO PMENU4 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

€ 23,0 SAY *Press any key to continue...’ 
wait subst 

READ 

SET CONFIRM ON 


GET 


CASE selectnum = 5 
* DO Update Leave and Absence Listings 


DO PMENUS 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

€ 23,0 SAY ‘Press any key to continue...’ 
wait subst 

READ 

SET CONFIRM ON 


GET 


CASE selectnum = 6 
* DO Print Reports 


DO PMENU6 


SET CONFIPM OFF 

STOFE I^ wait subst 

€ 23,0 SAY 'Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 
ENDCASE 


ENDDO T 
RETURN 
* EOF: 
SZ 


PMENU. PRG 





PRESS ; 
* Program: 
PMENU1 . PRG 
* Author.: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date...: 02/02/89 


* Notice.:Copyright (c) 1989, E. T. SHAW € JOAN ZIMMERMAN, 
All Rights Reserved 
* Notes....:UPDATE PERSONNEL LISTING 
SET TALK OFF 
SET BELL OFF 
SET ESCAPE OFF 
SET CONFIRM ON 
SELECT A 
USE TDA INDEX TDA 
SELECT B 
USE PERSON INDEX P_TDA 
SELECT A 
JOIN WITH B TO TEMP FOR TDA_PARA=b->TDA_PARA .AND. ; 
TDA_LINE=b->TDA_LINE .AND. TDA_POSN=B->TDA_POSN 
CLOSE ALL E 
DO WHILE .T. 
* ---Display menu options, centered on the screen. 
* draw menu border and print heading 
CLEAR 
2, O TO 14,79 DOUBLE 
3,17 SAY [UP DAT E PERSONNEL LISTIN 
G] 
4,1 TO 4,78 DOUBLE 
---display detail lines 
7,30 SAY [1. ADD DEPARTMENT PERSONNEL] 
8,30 SAY [2. CHANGE INFORMATION ON A PERSON) 
9,30 SAY [3. DELETE PERSON FROM LISTING] 
10,30 SAY [4. REVIEW ALL DEPARTMENT PERSONNEL 
INFORMATION] 
E1530 SAY 'O. EXIT’ 
STORE O TO selectnum 
8 14,33 SAY " select " 
Q 14,42 GET selectnum PICTURE "9" RANGE 0,4 
READ 


DODO » 0 aD o» 


DO CASE 
CASE selectnum = 0 
CLEAR ALL 
RETURN 


CASE selectnum = 1 
* DO ADD INFORMATION 
Adding = .T. 
DO WRILE Adding 
CLEAR 
M_TDAPARA = 0 
M TDALINE = 0 
M TDAPOSN = 0 
M code = SPACE (5) 
@ 6,0 TO 10,79 DOUBLE 
@ 7,10 SAY "ENTER TRE ID CODE OF THE PERSON YOU 
ADD:" GET M CODE PICTURE "19999" 
@ 8,10 SAY "or Press Return to QUIT" 
READ 


WISH TO 


IE M-CODE -» " " 
Adding = .F. 
LOOP 
ENDIF 
USE PERSON 
GO TOP 
LOCATE FOR IDCODE=m_code 
IF FOUND () 
CLEAR 
MESSAGE = "ID CODE REQUESTED IS ALREADY USED 


BY TRE PERSON SHOWN BELOW!" 


SET FORMAT TO CONFIRM 
READ 
CLOSE FORMAT 
LOOP 
ELSE 
TRY = ,T. 


DO WRILE TRY 


@ 12,0 TO 14,79 DOUBLE 
@ 13,5 SAY "TDA POSITION NOT AUTRORIZED, 


PETITRN TO TRY AGAIN...” 
WAIT " " 
LOOP 
ENDIF 
USE PERSON 
GO TOF 
LOCATE FOR TDA PARA«cM TDAPAFA .AND. 


TDA LINE-M TDALINE .AND. TDA POSNeM TDAPOSN 


IF FOUND () 
CLEAR 
SET FORMAT TO OCCUPIED 
READ 
CLOSE FORMAT 
8 15,0 
SET FORMAT TO CHOICE 
READ 
DO CASE 


CASE ANSWER=1 
REPLACE TDA_POSN WITH 99 
SET FORMAT TO PERSON 
APPEND BLANK 
REPLACE IDCODE WITH M_CODE,; 
TDA_PARA WITH M_TDAFARA, ; 


TDA_LINE WITH M_TDALINE, ; 


TDA POSN WITH M TDAPOSN 
PEAD 
CLOSE FORMAT 
TRY = ,F, 
LOOP 


ANSWER*2 

SET FORMAT TO PEFSON 

APPEND BLANK 

REFLACE IDCODE WITH M CODE,; 
TDA PARA WITH M TDAPAPA, 


CASE 


“es 


TDA LINE WITH M TDALINE, 


^e 


TDA POSN WITH 99 


READ 
CLOSE FORMAT 
TRY = .F. 
LOOP 

CASE ANSWER=3 
LOOP 

ENDCASE 

ELSE 
SET FORMAT TO PERSON 


APFEND BLANK 

REPLACE IDCODE WITH M_CODE,; 
TDA PARA WITH M_TDAPARA, 
TDA LINE WITH M_TDALINE, 
TDA_POSN WITH M_TDAPOSN 

READ 

CLOSE FORMAT 

TRY e .F. 

ENDIF 


ENDDO 


ENDIF 

YESNO 2 " " 

8 6,0 TO 8,79 DOUBLE 

8 7,15 SAY "DO YOU WISH TO ENTER SOCIAL ROSTER 
INFORMATION" GET YESNO PICTURE "!" 
READ 

IF YESNO = "Y" 

d SET FORMAT TO PRIVATE 

x APPEND BLANK 

a REPLACE IDCODE WITH M_IDCODE 

> CLOSE FORMAT 

*ENDIF 

*ENDDO (ADDING) 

SET CONFIPM OFF 


M_TDAPARA = O STOPE ' ' TO wait subst 
CLEAR 8 23,0 SAY ‘Press any key to continue...’ GET 
SET FORMAT TO TDAINPUT wait subst 
READ READ 
CLOSE FORMAT SET CONFIRM ON 
USE TDA 
GO TOP CASE selectnum = 2 
LOCATE FOR TDA_PAPA=M_TDAPARA AND. * DO CHANGE INFOPMATION 
TDA_LINE=M_TDALINE «AND. TDA POSN=M TDAPOSN * SEEK M CODE 
IF FOUND () B Gë * IF BLANK, EXIT 
SET FORMAT TO POSITION * IF FOUND () 
READ E SET FOPMAT TO PERSON 
CLOSE FORMAT x CRECK TO INSURE FOSITION IS NOT OCCUFIED BY 
ELSE SOMEONE * IF OCCUPIED 
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* SET FORMAT TO CHOICE 

x GET CHOICE AND EXECUTE PER ADDING 
INSTRUCTIONS 

S ENDIF 


*ELSE (i.e. NOT FOUND) 
* NOTIFY USER ID NOT FOUND, 
BY LAST NAME 


GIVE OPTION TO SEARCH 


* SEEK LAST NAME 

* DISPLAY ALL WITH THIS LAST NAME, FIRST NAME AND 
ID CODE 

» GIVE USER OPTION TO CHOSE WHICH RECORD NUMBER 

* USER PICKS RECORD NUMBER 

* GOTO RECORD SELECTED 

* SET FORMAT TO PERSON 

* CHECK TO INSURE POSITION IS NOT OCCUPIED BY 
SOMEONE x IF OCCUPIED 

x SET FORMAT TO CHOICE 

e GET CHOICE AND EXECUTE PER ADDING 
INSTRUCTIONS 

£ ENDIF 

CLEAR 


@ 6,0 TO 8,79 DOUBLE 
@ 7,15 SAY "DO YOU WISH TO CHANGE SOCIAL ROSTER 
INFORMATION" GET YESNO PICTURE "|!" 
READ 
IF YESNO » "Y" 
*USE PRIVATE INDEX IDCODE 
*LOCATE FOR IDCODE-M IDCODE 
*IF FOUND() DO FOLLOWING 
* SET FORMAT TO PRIVATE 
* APPEND BLANK 
* REPLACE IDCODE WITH M_IDCODE 
* CLOSE FORMAT 
*ENDIF 
*IF .NOT. FOUND () 
* WAIT "ADDING A NEW RECORD, 
FOUND..PRESS ; 
*RETURN TO CONTINUE..." 
* SET FORMAT TO PRIVATE 
* APPEND BLANK 
* REPLACE IDCODE WITH M_IDCODE 
* CLOSE FORMAT 
*ENDIF 
*ENDIF 
SET CONFIRM ON 


&GIDCODE NOT IN PRIVATE FILE 
IDCODE NOT 


CASE selectnum = 3 
* DO REMOVE INFORMATION 


€ 6,0 TO 10,79 DOUBLE 
€ 7,10 SAY "ENTER THE ID CODE OF THE PERSON YOU 


WISH TO REMOVE :" GET M_CODE PICTURE "!9999" 

€ 8,10 SAY "or Press Return to QUIT" 

READ 

* SEEK M_CODE 

*IF BLANK, EXIT 

SIE FOUND () 

*MESSAGE = " IS THIS THE PERSON YOU WANT TO DELETE? 
(Y/N)" 


SET FORMAT TO CONFIRM 
READ ANSWER 
IF ANSWER IS NO 
LOOP 
ENDIF 
IF ANSWER IS YES "Y" 
ASK "ARE YOU SURE (Y/N)” 
IF SURE IS YES "Y" 
LOCATE AND DELETE 
USE ABSENSE 
LOCATE AND DELETE 
IF NOT FOUND() CONTINUE 
USE CMEREQ 
LOCATE AND DELETE 
IF NOT FOUND() CONTINUE 
USE PRIVATE 
LOCATE AND DELETE 
IF NOT FOUND() CONTINUE 
ELSE (ANSWER IS NO "N”) 
CLEAR 
85,0 
MAIT 
ENDIF 
*ELSE (i.e. NOT FOUND) 
* NOTIFY USER ID NOT FOUND, GIVE OPTION TO SEARCH 
BY LAST NAME 
* IF CHOICE IS TO SEEK BY LAST NAME 
* SEEK LAST NAME 
` DISPLAY ALL WITH THIS LAST NAME 
` GIVE USER OPTION TO CHOSE MHICH RECOPD 


"N" 
TO TRY ANOTHER PERSON CODE 


(IN PERSON) 


» » $$ P» 9?» $$ 9 5» P» P» sg sg gg B? $9 gg sg P»? sg P5 D 


NUMBER 
e USER PICKS RECORD NUMBER 
£ GOTO RECORD SELECTED 
* DISPLAY LAST NAME, FIRST NAME, MI and FANK 
i ASK "IS THIS THE PERSON YOU WISH TO DELETE? 
(Y/N)" 
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READ ANSWER 
IF ANSWER IS NO "N" 
LOOP TO TRY ANOTHER PERSON CODE 
ENDIF 
IF ANSWEF IS YES "Y" 
STORE IDCODE TO M IDCODE &IDCODE OF CURR 


» * »  » » 


PERSON 


+ 


ASK "ARE YOU SURE (Y/N)" 
TE SURE IS YES oy? 
LOCATE M_IDCODE AND DELETE 


» * 


(IN 
PERSON) 
USE ABSENSE 
LOCATE AND DELETE 
IF NOT FOUND() CONTINUE 
USE CMEREQ 
LOCATE M_IDCODE AND DELETE 
IEF NOT FOUND () CONTINUE 
USE PRIVATE 
LOCATE M_IDCODE AND DELETE 
IF NOT FOUND () CONTINUE 
ELSE (ANSWER IS NO "N”) 
CLEAR 
85,0 
WAIT 
ENDIF 
ENDIF 
IF CHOICE IS NOT TO SEARCH FOR LAST NAME 
LOOP TO BEGINNING 
ENDIF 
*ENDIF 
€ 6,0 TO 8,79 DOUBLE 
@ 7,15 SAY "DO YOU WISH TO CHANGE SOCIAL ROSTER 
INFORMATION" GET YESNO PICTURE "!" 
READ 
*IF YESNO = "Y" 
*USE PRIVATE INDEX IDCODE 
*LOCATE FOR IDCODE-M IDCODE 
*IF FOUND() DO FOLLOWING 
*SET FORMAT TO DELPRIVATE 
*ASK "ARE YOU SURE (Y/N)" 
*IF SURE IS YES "Y" 
x DELETE 
*ELSE (ANSWER IS NO "N") 
: CLEAR 
A 85,0 
x WAIT 
*ENDIF 
*ENDIF 
*IF .NOT. 
E WAIT 
CONTINUE..." 
* ENDIF 
* 
SET TALK ON 
CLEAR 
8 2,0 SAY ' ' 
? 'PACKING DATABASE TO REMOVE RECORDS MAFKED 
DELETION' 
*PACK ALL DATABASES USED 
(PERSON, CMEREQ, ABSENCE, PRIVATE) 
SET CONFIRM OFF 
STORE ' ' TO wait subst 
€ 23,0 SAY “Press any key to continue...” 
wait subst 
READ 
SET CONFIRM ON 


Ss sg gg sg gg 5» sg gg gg gg sg 


FOUND() &&IDCODE NOT IN PRIVATE FILE 
"IDCODE NOT FOUND..PFESS RETUFN TO 


FOR 


SET TALK OFF 


GET 


CASE selectnum = 4 
* DO REVIEW INFORMATION 66 ONLY PERSON FILE 
BROMSE NOAPPEND NOMENU 
SET CONFIRM OFF 
STORE * ' TO wait subst 
€ 23,0 SAY ’Press any key to continue...’ 
wait subst 
READ 
SET CONFIRM ON 


GET 


ENDCASE 


ENDDO T 
RETURN 

© POF: 

"2 


FHFNT1.PRG 


* Program..: 
PMENU2 .PRG 


ELBERT T. 
02/02/89 
* Notice.:Copyright (c) 
All Rights Reserved 

* Notes....:UPDATE TDA LIST 
SET TALK OFF 

SET BELL OFF 


* Author...: SHAW & JOAN ZIMMERMAN 


1989,ELBERT T. SHAW & JOAN ZIMMERMAN, 


SET ESCAPE OFF 
SET CONFIRM ON 


USE TDA 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
x draw menu border and print heading 
CLEAR 
8 2, O TO 14,79 DOUBLE 
@ 3,23 SAY (UP DATE TDA LISTING) 
@ 4,1 TO 4,78 DOUBLE 
* ---display detail lines 
€ 7,30 SAY [1. ADD A TDA POSITION] 
@ 8,30 SAY (D. CHANGE A TDA POSITION’S INFORMATION] 
@ 9,30 SAY [3. REMOVE A TDA POSITION) 
@ 10,30 SAY (4. REVIEW ALL TDA POSITIONS] 
eee, 30 SAY ’O. EXIT’ 
STORE O TO selectnum 
@ 14,33 SAY " select s 
€ 14,42 GET selectnum PICTURE "9" RANGE 0,4 
READ 
DO CASE 
CASE selactnum = 0 
CLEAR ALL 
RETURN 


CASE selectnum = 1 


* 
* 


LIST 


PRESS ; 


(Y/N)"; 


DO ADD INFORMATION 
ALLOWS YOU TO ADD A NEW TDA POSITION TO THE MASTER 
TRYING = .T. 
DO WHILE TRYING 
SET FORMAT TO TDAINPUT 
READ 
CLOSE FORMAT 
USE TDA 
GO TOP 
LOCATE FOR TDA_PARA=M_TDAPARA .AND. 
TDA_LINE=M_TDALINE .AND. TDA_POSN=M_TDAPOSN 
IF FOUND () 
CLEAR 
SET FORMAT TO OCCUPIED 
READ 
CLOSE FORMAT 
ELSE 
@ 12,0 TO 14,79 DOUBLE 
@ 13,5 SAY "TDA POSITION NOT IN CURRENT FILE, 


RETURN TO ADD IT..." 
WAIT "" 
CLEAR 
M_AUTH = SPACE (1) 
@ 6,0 TO 8,79 
@ 7,15 SAY "IS THIS AN AUTHORIZED POSITION? 


GET M AUTH PICTURE "I" 
READ 
SET FORMAT TO TDA 
APPEND BLANK 
IF M AUTH s "Y" 
REPLACE AUTH WITH 1 
ELSE 
REPLACE AUTN 
ENDIF 
REPLACE TDA PARA WITH M TDAPARA, 
TDA LINE WITH M TDALINE, 
TDA POSN WITH M TDAPOSN 


WITH O 


ws me 


READ 
CLOSE FORMAT 
ENDIF 
ENDDO 
SET CONFIRM OFF 
STORE ' ' TO wait subst 


8 23,0 SAY “Press any key to continue...” GET 


wait subst 


CASE 


* 
$ 


POSITION’S 


TDA_LINE=M_TDALINE 


READ 
SET CONFIRM ON 


selectnum = 2 
DO CHANGE INFORMATION 
ALLOWS YOU TRE CAPABILITY TO CHANGE A 
INFO 
TRYING = ,T. 
DO WHILE TRYING 
SET FORMAT TO TDAINPUT 
READ 
USE TDA 
GO TOP 
LOCATE FOR TDA_PARA=M_TDAPAFA .AND. 
«AND. TDA_POSN=M TDAPOSN 


TDA 


IF FOUND () 
CLEAR 
IF AUTH = 0 
@ 6,0 TO 8,79 
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AN 


AUTHORIZED POSITION? 


€ 7,15 SAY "DO YOU WANT TO CHANGE THIS TO 
(Y/N)" GET HM AUTH PICTURE "!" 
READ 
IF M AUTH e "Y" 
FEFLACE AUTH WITH 1 
ENDIF 
SET FORMAT TO TDA 
READ & CANNOT CHANGE 
CLOSE FORMAT 
ELSE c4 IF AUTR = O 
@ 6,0 TO 8,79 
@ 7,15 SAY "DO YOU WANT TO CHANGE THIS TO 


TRE TDA POSITION 


AN UNAUTHORIZED POSITION? (Y/N)" GET M AUTH PICTURE "!" 


PRESS ; 


READ 
IF M AUTH = "Y" 
REPLACE AUTH WITH O 
ENDIF 
SET FORMAT TO TDA 
READ & CANNOT CHANGE THE TDA POSITION 
CLOSE FORMAT 
ELSE 
€ 12,0 TO 14,79 DOUBLE 
€ 13,5 SAY "TDA POSITION NOT IN CURRENT FILE, 


RETURN TO TRY AGAIN..." 


WAIT " ” 
LOOP 
ENDIF 
ENDDO 
SET CONFIRM OFF 


STORE ’ ' TO wait subst 

@ 23,0 SAY ’Press any key to continue...’ GET 
wait subst 

READ 


SET CONFIRM ON 


CASE selectnum = 3 


* 
* 


DO REMOVE INFORMATION 
ALLONS YOU TO DELETE A NO LONGER AUTHORIZED TDA 
POSITION 
TRYING = ,T. 
DO WBILE TRYING 
SET FORMAT TO TDAINFUT 
READ 
USE TDA 
GO TOP 
LOCATE FOR TDA PARA-M TDAPARA .AND. 


TDA LINE-M TDALINE .AND. TDA POSNeM TDAPOSN 


TO 


TDA POSN TO 


TDA LINE-M TDALINE .AND. 


IS 


OCCUPYING THE DELETED 


IF FOUND () 
YESNO = SPACE (1) 
CLEAR 
0.270 
? "JOBTITLE 
? JOBTITLE,APC 
@ 6,0 TO 8,79 DOUBLE 
@ 7,15 SAY "IS THIS THE TDA POSITION YOU WANT 


APC CODE” 


DELETE? (Y/N)" GET YESNO PICTURE "!" 


READ 
IF YESNO e "Y" 
DELETE 
USE PERSON 
INDEX ON TDA PARA .AND. TDA LINE .AND. 
TEMP 
SET INDEX TO TEMP 
LOCATE FOR TDA_PARA=M_TDAFARA .AND, 
TDA_POSN=M_TDAPOSN 
IF FOUND () 
REPLACE TDA_PARA WITH O, ; 
TDA_LINE WITH O, ; 
TDA_POSN WITH O 
CLEAR 
@ 6,0 TO 9,79 DOUBLE 
@ 7,5 SAY "FOUND "+RANK+" 


"+LNAME+" WHO 


POSITION, IDCODE 


IS"+STR(IDCODE, 5) 


PERSON’S TDA 


PRESS ; 


@ 8,5 SAY "BE SURE YOU UPDATE TRIS 
POSITION WITH A VALID TDA POSITION!" 
@ 12,0 
WAIT 
ENDIF 
ELSE tt YESNO= "N" 
LOOP 
ENDIF 


ELSE &&POSITION WAS NOT FOUND 
8 12,0 TO 14,79 DOUBLE 


@ 13,5 SAY "TDA POSITION NOT IN CURRENT FILE, 
RETUPN TO TRY AGAIN..." 
WAIT " " 
LOOP 
ENDIF 


ENDDO 


SET INDEX TO 

ERASE TEMP .NDX 

SET TALK ON 

CLEAP 

@ 2,0 SAY 

? 'PACKING DATABASE TO REMOVE RECORDS MARKED FOR 
DELETION' 

PACK 

SET TALK OFF 

SET CONFIFM OFF 

STORE ' ' TO wait subst 

8 23,0 SAY 'Press any key to continue... 

wait subst 
READ 
SET CONFIRM ON 


, € 


MODIFY? ( 


, 


GET 


CASE selectnum = 4 
* DO REVIEW INFORMATION 
* ALLOWS YOU TO REVIEW THE 


COMPLETE FILE (MM/DD/YY 
INDEX ON TDA_PARA .AND. TDA_LINE .AND. TDA_POSN TO 
TEMP 
SET INDEX TO TEMP 
BROWSE NOAPFEND NOMENU 
ERASE TEMP .NDX 
SET CONFIRM OFF 
STORE ' ' TO wait subst 
8 23,0 SAY *Press any key to continue.. 
walt_subst 
READ 
SET CONFIRM ON 


$ 
D 


GET 


ENDCASE 


ENDDO T 
RETURN 
* FOF: 
az 


PMENUZ.PRG 


* Program.. 
PMENU3.PRG 


BY 


* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date.....: 02/02/89 
* Notice: Copyright (c) 
All Rights Reserved 

* NOTES QUICK UPDATE FROM RIR REPORT 
SET TALK OFF 

SET BELL OFF 

SET ESCAPE OFF 

SET CONFIRM ON 

USE PERSON 

DO WHILE .T. 


1989, ELBERT T. SHAW & JOAN ZIMMERMAN, 


DELETE? (Y 


* --—-Display menu options, centered on the screen. 

* draw menu border and print heading 

CLEAR 

€ 2, O TO 12,79 DOUBLE 

@ 3,13 SAY (QU ICK 
EPOR T) 

€ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

@ 7,23 SAY (1. Update Losses) 

@ 8,23 SAY (2. Update Changes to TDA Positions) 

@ 10, 23 SAY “0. EXIT’ 

STORE O TO selectnum 

@ 12,33 SAY " select 

@ 12,42 GET selectnum PICTURE 

READ 


UPDATE F ROM RI R R 


PERSON) 


r 


"9" RANGE 0,2 


DO CASE 
CASE selectnum = O 
CLEAR ALL 
RETURN 


CASE 


* 


selectnum = 1 
DO Update Losses 


*DO MHILE TRYING && MASTER LOOP FOR MULTIPLE 
ENTRIES 


M_UPDATETYPE = 1 

@ 6,0 TO 9,79 DOUBLE 

€ 7,10 SAY "HAS THIS PERSON ACTUALLY DEPARTED OR IS 
AN UPDATE TO A PROJECTED LOSS DATE? (ACTUAL=0, 
DATE=1)" GET M_UPDATETYPE PICTURE "9" RANGE 0,1 

READ 


TRIS 
UPDATE 


wait subs 
@ 15,0 TO 19,79 DOUBLE 
@ 16,10 SAY "ENTER THE ID CODE OF THE PEPSON 
WHO"*IFF(M UPDATETYPE el, "LOSS DATE NEEDS CHANGING", 
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"DEPARTED")*":" GET M CODE PICTURE "19999" 


8 17,10 SAY "or Press Return to QUIT" 
READ 
*USE PERSON 
* SEEK 21 CODE 
*IF BLANK, EXIT 
*IF FOUND () 
* DISFLAY LAST NAME, FIRST, AND RANK 
MESSAGE = "IS THIS THE PERSON YOU WISH TO 
Y/N)" 
SET FORMAT TO CONFIRM 
IF ANSWER IS NO "N" 
LOOP TO TRY ANOTHER PERSON CODE 
ENDIF 
IF ANSWER IS YES "y" 
IF M_UPDATETYPE IS 1 
CLEAR 
@ 6,0 TO 8,79 DOUBLE 
@ 7,15 SAY "ENTER NEW LOSS DATE: 


* 


&GAPPEND NEW LOSS DATE 


* 
a 
* 
a 
* 
* 
* 
* 
) 
* GET M LOSS PICTURE "99/99/99" 
z READ 
* REPLACE ALOSS MITH M LOSS 
* LOOP TO DO ANOTHER PERSON 
* ENDIF 
£ ASK "ARE YOU SURE (Y/N)" 
$ IF SURE IS YES "y" 
> LOCATE AND DELETE {IN PERSON) 
* USE ABSENSE 
* LOCATE AND DELETE 
Ge IF NOT FOUND() CONTINUE 
* USE CMEREQ 
d LOCATE AND DELETE 
£ IF NOT FOUND () CONTINUE 
* USE PRIVATE 
* LOCATE AND DELETE 
G IF NOT FOUND () CONTINUE 
i ELSE (ANSWER IS NO "N") 
E CLEAR 
e 85,0 
* WAIT 
* ENDIF 
*ELSE (i.e. NOT FOUND) 
$ NOTIFY USER ID NOT FOUND, GIVE OPTION TO SEARCH 
LAST NAME 
IF CHOICE IS TO SEEK BY LAST NAME 
SEEK LAST NAME 
DISPLAY ALL WITH THIS LAST NAME 
GIVE USER OPTION TO CHOSE WHICH ID CODE 
USER PICKS ID CODE 
GOTO ID CODE SELECTED 
DISPLAY LAST NAME, FIRST NAME, MI and RANK 
MESSAGE="IS THIS TRE PERSON YOU WISH TO 
N) 
SET FORMAT TO CONFIRM 
READ ANSWER 
IF ANSWER IS NO "N” 
LOOP TO TRY ANOTHER PERSON CODE 
ENDIF 
IF ANSWER IS YES "Y" 
STORE IDCODE TO M_IDCODE 
ASK "ARE YOU SURE (Y/N)" 
IF SURE IS YES "Y" 
LOCATE M IDCODE AND DELETE (IN 


SS ww Sp RE Es E E SW SW 


USE ABSENSE 
LOCATE AND DELETE 
IF NOT FOUND() CONTINUE 
USE CMEREQ 
LOCATE M IDCODE 
IF NOT FOUND () 
USE PRIVATE 
LOCATE M_IDCODE 
IF NOT FOUND () 
ELSE (ANSWER IS NO 
CLEAR 
85,0 
WAIT 
ENDIF 


AND DELETE 
CONTINUE 


AND DELETE 
CONTINUE 
"N") 


ENDIF 

IF CHOICE IS NOT TO SEARCH FOR LAST NAME 
LOOP TO BEGINNING 

ENDIF 

*ENDIF 

*ENDDO 


* 


Ss gw gg gw gg Se »? » » » » a 


* 


SET CONFIPM OFF 

STORE ' ' TO wait subst 

€ 23,0 SAY ‘Press any key to continue...” 
E 

PEAD 

SET CONFIPM ON 


GET 


TDA_LINE=M_TDALINE 


CASE selectnum = 2 


* 


DO Update Changes to TDA Positions 


*DO MHILE TRUE 

*ALLOWS YOU TO CHANGE THE TDA POSITION FROM THE RIR 
SET FORMAT TO PERRIR && screen of memory variable 
READ 

*IF M_TDAPARA = 0 

E EXIT 

* ENDIF 

*USE PERSON 

*LOCATE FOR TDA_PARA=M_TDAPARA .AND. 

* AND. TDA_POSN=M_TDAPOSN 


*1F FOUND().. MEANS THAT TRE NEN POSITION IS 
OCCUPIED, GIVE CROICES AS LISTED BELOW 
` STORE IDCODE TO OLDPERSON &&RECORD WHO THE 
PERSON * CLEAR 
* e 7,0 
* SET FORMAT TO CHOICE 
* READ 
* DO CASE 
^ CASE ANSWER-1 
* USE TDA 
* && LOOK FOR THE TDA TO MAKE SUFE IT IS 
O.K 
^ LOCATE FOR TDA PARA-M TDAPARA .AND. 
TDA LINE-M TDALINE .AND. TDA POSN-M TDAPOSN 
* IF FOUND() &&AUTBORIZED SLOT 
* USE PERSON 
^ LOCATE FOR IDCODE=M IDCODE 6&& PERSON 
TO CHANGE POSN m 
* IF .NOT. FOUND () 
* CLEAR 
* € 6,0 TO 8,79 DOUBLE 
* € 7,15 SAY "IDCODE DOES NOT EXIST, 
PRESS RETURN TO TRY AGAIN.." 
` LOOP 
* ENDIF 
` REPLACE TDA_PARA WITH M TDAPARA, ; 
* TDA LINE WITH M TDALINE, ; 
* TDA POSN WITH M TDAPOSN 
* GO TOP 
* LOCATE FOR IDCODE-OLDPERSON 
* REPLACE TDA_POSN WITH 99 &&FUT TRE 
OLDE PERSON IN EXCESS 
a ELSE 
* € 6,0 TO 8,79 DOUBLE 
* 8 7,5 SAY "TDA POSITION ENTERED IS 
NOT AN AUTHORIZED TDA POSITION" 
*CHECK INFORMATION AND PRESS RETURN TO TRY 
AGAIN..." 
* WAIT " " 
* LOOP 
* ENDIF 
* REPLACE TDA POSN WITH 99 
* TRY = .F. 
* LOOP 
CASE ANSWER=2 
* USE TDA 
^ && LOOK FOR THE TDA TO MAKE SURE IT IS 
OK. 
^ LOCATE FOR TDA_FARA=M_TDAPARA .AND. 
TDA_LINE=M_TDALINE .AND. TDA_POSN=M_TDAPOSN 
^ IF FOUND() &&AUTHORIZED SLOT 
* USE PERSON 
* LOCATE FOP IDCODE-M IDCODE 66 PERSON 
TO CHANGE POSN 
* IF .NOT. FOUND() 
* CLEAR 
* € 6,0 TO 8,79 DOUBLE 
* 


PRESS RETURN 


€ 7,15 SAY "IDCODE DOES NOT EXIST, 
TO TRY AGAIN.." 


* LOOP 

* ENDIF 

* REPLACE TDA PARA MITH M TDAPARA, ; 

* TDA LINE WITH M TDALINE, ; 

* TDA_POSN WITH 99 

* GO TOP 

` LOCATE FOR IDCODE=OLDPEPSON 

^ REPLACE TDA FOSN WITH 99 &&PUT THE 
OLDE PERSON IN EXCESS 

* ELSE 

* € 6,0 TO 8,79 DOUBLE 

* @ 7,5 SAY "TDA POSITION ENTEFED IS 
NOT AN * AUTHORIZED TDA POSITION 

*CRECK INFORMATION AND PRESS RETURN TO TRY 
AGAIN..." 

* WAIT " " 

* LOOP 

* ENDIF 

* TRY = .F. 

* LOOP 

e CASE ANSWER=2 


2:5 


: LOOP 

a ENDCASE 

*ELSE — &&FERSON NOT FOUND () 

* — CLEAF 

* USE TDA 

* LOCATE FOR TDA_PARA=M_TDAPARA .AND. 
TDA_LINE=M_TDALINE .AND. TDA_POSN=M_TDAPOSN 

* IF FOUND() &&AUTBORIZED SLOT 


IN POSITION DESIRED 


` USE PERSON 

` LOCATE FOR IDCODE=M_IDCODE 46 PERSON TO 
CHANGE POSN 

* IF .NOT. FOUND (|) 

* CLEAR 

* € 6,0 TO 8,79 DOUBLE 

e € 7,15 SAY "IDCODE DOES NOT EXIST, PRESS 
RETURN TO TRY AGAIN.." 

` LOOP 

s ENDIF 

e REPLACE TDA_FARA WITH M_TDAPAPA, ; 

* TDA LINE WITH M TDALINE, ; 

e TDA_POSN WITH M_TDAPOSN 

* ELSE 

: € 6,0 TO 8,79 DOUBLE 

a @ 7,5 SAY "TDA FOSITION ENTERED IS NOT AN 
AUTHORIZED TDA POSITION" 

*CHECK INFORMATION AND PRESS RETURN TO TRY 
AGAIN..." 

` WAIT " " 

` LOOP 

* ENDIF 


SET CONFIRM OFF 

STORE * ' TO wait subst 

e 23,0 SAY 'Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 
ENDCASE 


ENDDO T 
RETURN 
* EOF: 
no 


PMENU3.PRG 





* Program..: 


PMENU4. PRG 


* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date. OZ OZ OO 

* Notice: Copyright (c) 1989, ELBERT T. 
ZIMMERMAN, All Rights Reserved 

* Notes....: UPDATE CME LIST/BUDGET 


SHAW € JOAN 


SET TALK OFF 
SET BELL OFF 
SET ESCAPE OFF 
SET CONFIRM ON 


DO WHILE .T. 
* ---Display menu options, centered on the screen. 
E draw menu border and print heading 
CLEAR 
e 2, O TO 14,79 DOUBLE 
@ 3,19 SAY (UPDATE CEUMEE INFORMA TION] 
@ 4,1 TO 4,78 DOUBLE 
* ---display detail lines 
@ 7,20 SAY [1. Update Allocation for Fiscal Year) 
@ 8,20 SAY [2. Update CME Requests] 
@ 9,20 SAY [3. Update CME Requests with Actual Costs] 
€ 10,20 SAY (4. Print Reports] 
(682, 20 SAY 10. EXIT: 
STORE O TO selectnum 
@ 14,33 SAY " select S 


@ 14,42 GET selectnum PICTURE "9" RANGE 0,4 
READ 


DO CASE 
CASE selectnum = O 
CLEAR ALL 
RETURN 


CASE selectnum = 1 
* DO Update Allocation for Fiscal Year 


DO pmenud 1 


SET CONFIRM OFF 

STORE * * TO wait subst 

e 23,0 SAY 'Press any key to continue..." 
wait subst 

READ 

SET CONFIRM ON 


GET 


CASE selectnum - 2 
* DO Update TME Pequests 


DO PMENU4 2 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY ’Press any key to continue...” GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 3 
* DO Update CME Requests with Actual Costs 


DO PMENU4 3 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY 'Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 4 
* DO Print Reports 


DO PMENU4_4 

SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY “Press any key to continue...” 
wait subst 

READ 

SET CONFIRM ON 


GET 


ENDCASE 


ENDDO T 
RETURN 

* EOF: 

22 


PMENU4. PRG 





* Program..: 


PMENU4 1.PRG 


*OAUChoOroi 
* Date.....: 02/02/89 

* Notice...: Copyright (c) 1989, ELBERT T. SHAW & JOAN 
ZIMMERMAN, All Rights Reserved 

* Notes....: UPDATE ALLOCATION FOR FY 


ELBERT T. SHAW & JOAN ZIMMERMAN 


SET TALK OFF 

SET BELL OFF 

SET ESCAPE OFF 

SET CONFIRM ON 

MEI e Oo 

* Clear Screen for FY input an allow for the user to select 
the Fiscal Year 


* Typically, the user will only be operating in one FY 


CLEAR 
@6,0 to 8,79 DOUBLE 
@7,15 SAY “Enter the Fiscal Year for the CME Allocations:" ; 


GET M_FY PICTURE "99" 
READ 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
* draw menu border and print heading 
CLEAR 


M ALLOCATION = 0 
@ 6,0 TO 9,79 DOUBLE 
€ 7,15 SAY "ENTEF ALLOCATION FOP FISCAL YEAR 
"+STR(M_FY, 2) 
GET M ALLOCATION PICTURE 7999999.99" 
€ 8,15 SAY "OR PRESS RETURN TO QUIT" 
READ 
IF M ALLOCATION - O 
EXIT 
ENDIF 
USE CMEALLOC 
LOCATE FOR FY=M_FY 
IF FOUND () 
CLEAR 
@ 6,0 TO 8,79 DOUBLE 
€ 7,15 SAY “ALLOCATION FOR FISCAL YEAP "+STR(M FY,2)+" 
ALREADY EXISTS"; 
@ 8,15 SAY "PRESS RETURN TO EDIT IT" 


2236 


WRIT 9 
SET FORMAT TO CMEALLOC 
READ 
LOOF 
ELSE 44 ALLOCATION FOR FY IS A NEW ONE 
APPEND BLANK 
REPLACE ALLOCATION WITH M ALLOCATION 
REPLACE FY WITH M_FY 
LOOP 
ENDIF 
ENDDO T 
RETURN 
* EOF: PMENU4 1.PRG 
AZ 


* Program..: 
PMENU4_2.PRG 


* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date.....: 02/02/89 
* Notice...: Copyright (c) 1989,ELBERT T. SHAW & JOAN 


ZIMMERMAN, All Rights Reserved 
* Notes....: UPDATE CME REQUESTS 


SET TALK OFF 

SET BELL OFF 

SET ESCAPE OFF 

SET CONFIRM ON 

M FY = 0 

* Clear Screen for FY input an ellow for the user to select 
the Fiscal Year 

* Typically, the user will only be operating in one FY 


CLEAR 
@6,0 to 8,79 DOUBLE 
87,15 SAY "Enter the Fiscal Year for the CME Allocations:" ; 


GET M FY PICTURE "99" 
READ 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
* draw menu border and print heading 

CLEAR 

@ 2, 0 TO 14,79 DOUBLE 


@ 3,21 SAY [UF DATE CME 

@ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

@ 7,30 SAY [1. ADD A NEW CME REQUEST FOR FY 
J+STR(M_FY,2) 

@ 8,30 SAY [2. 
)*STR(M FY,2) 

@ 9,30 SAY (3. DELETE A CME REQUEST FOR FY }+STR(M_FY, 2) 

@ 10,30 SAY [4. REVIEW ALL CME REQUESTS FOR FY 
}+STR(M_FY, 2) 

@ 12, 30 SAY “O15 EXIT’ 

STORE O TO selectnum 

8 14,33 SAY " select v 

Q 14,42 GET selectnum PICTURE "9" RANGE 0,4 

READ 


REQUESTS] 


CRANGE A CME REQUEST'S INFORMATION FOP FY 


DO CASE 
CASE selectnum - O 
CLEAR ALL 
RETURN 


CASE selectnum = 1l 
* DO ADD INFORMATION 


DO MBILE .T. 
e 6,0 TO 9,79 DOUBLE 
e 7,15 SAY "ENTER THE ID CODE OF THE PEPSON TO ADD 
REQUEST: "; 
GET M IDCODE PICTURE "!999" 
8 8,15 SAY "OP FFESS RETUPN TO QUIT" 


THE 


IF M_IDCODE= "" 


EXIT 
ENDIF 


USE PERSON 

LOCATE FOR IDCODE=M_IDCODE 

IF FOUND() &&PERSON DOES EXIST IN MASTER FILE 
ANSWER = " " 
MESSAGE= "IS THIS TRE PERSON YOU EXPECTED? (Y/N) 


SET FOPMAT TO CONFIPM 
READ 


IF ANSWER - "Y" &&the right person 
USE CMEREQ 
SET FILTER TO FY-M FY 
(cjr) Pht 
SET FORMAT TO CMEREQ 
APPEND BLANK 
REPLACE IDCODE WITR M_IDCODE 
REPLACE FY WITH M FY 
READ ~ 
REPLACE TOTALCOST WITR 
TRAVELCOST+PERDIEM+REGFEE+REIMB 
CLOSE FORMAT 
SET FILTER TO 
LOOP 
ELSE 
LOOP 
ENDIF 
ELSE 
@ 6,0 TO 8,79 DOUBLE 
@ 7,15 SAY "THERE IS NOT A PERSON WITH TRAY 
IDCODE, PRESS RETURN TO TRY AGAIN...” 
WAIT " " 
LOOP 
ENDIF 
ENDDO 
SET CONFIRM OFF 
STORE * * TO wait subst 
@ 23,0 SAY 'Press any key to continue...’ GET 
wait subst 
READ 
SET CONFIRM ON 


CASE selectnum = 2 
* DO CHANGE INFORMATION 


DO WHILE .T. 


@ 6,0 TO 9,79 DOUBLE 

@ 7,15 SAY "ENTER TRE ID CODE OF THE PERSON YOU 
WANT TO CHANGE: " GET M IDCODE PICTURE "!999" 

@ 8,15 SAY "OR PRESS RETURN TO QUIT" 


IF M IDCODE- "" 
EXIT 
ENDIF 


USE PERSON 

LOCATE FOR IDCODE-M IDCODE 

IF FOUND() &&PEPSON DOES EXIST IN MASTER FILE 
ANSWER =" " 
MESSAGE= "IS THIS THE PEPSON YOU EXPECTED? (Y/N) 


SET FORMAT TO CONFIRM 


READ 
IF ANSWER - "Y" &&the right person 
USE CMEREQ 
SET FILTER TO IDCODE*M_IDCODE .AND. Fish EY 
CLEAR 
@ 6,0 


DISPLAY FIELDS IDCODE, TYPE, START, END WHILE 
IDCODE=M_IDCODE 
@ 20, O CLEAR 
@ 22,0 SAY "ENTER THE RECORD NUMBER OF TRE 
CME REQUEST YOU DESIRE TO CHANGE. (1-"+ 
STR (RECCOUNT () , 4) ^") ^; 
GET RECOPD PICTURE "9999" 
READ 
IF RECORD > O .AND. RECORD < RECCOUNT () 
CLEAR 
DO WRILE .T. 
@ 6,0 TO 8,79 DOUBLE 
@ 7,5 SAY "WILL COSTS BE ACTUAL COSTS OR 
ESTIMATED; 
(ENTER AN -A- FOR ACTUAL OR AN -E- FOR 
ESTIMATED)" GET M CCODE PICTURE "I" 
IF M CCODE 4 "A" .OR. M CCODE 4 "E" 
CLEAR 
Q 6,0 TO 8,79 DOUBLE 
8 7,15 SAY "YOU RAVE ENTEPED A WRONG 


LETTER, PRESS FETUFN TO TPY AGA!H.." 
WAIT " " 
LOOP 
ENDIF 


GOTO RECORD 
SET FORMAT TO CMEREQ 
REPLACE C CODE WITH M CCODE 
READ 
REPLACE TOTALCOST MITA 
TRAVELCOST+PERDIEM+REGFEE+REIMB 
CLOSE FORMAT 
EXIT 
ENDDO 
ELSE 
@ 20,0 CLEAR 
@ 23,5 SAY "NO SUCR RECORD: 
"+STR (RECORD, 4) 


? CBR(7) 
WAIT 
ENDIF 
SET FILTEF TO 
LOOF 
ELSE 
SET FILTEP TO 
LOOP 
ENDIF 
ELSE 
e 
e 
IDCODE, PRESS RETURN TO TRY AGAIN..." 
WAIT " " 
LOOP 
ENDIF 
ENDDO 
SET FILTER TO 


6,0 TO 8,79 DOUBLE 
> 


SET CONFIRM OFF 

STORE ' * TO wait subst 

€ 23,0 SAY 'Press any key to continue... 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum - 3 
* DO REMOVE INFORMATION 


DO WHILE .T. 
@ 6,0 TO 9,79 DOUBLE 


,15 SAY "THERE IS NOT A PERSON WITH THAT 


' GET 


0€ 7,15 SAY "ENTER THE ID CODE OF THE FERSON TO 
DELETE TREIR REQUEST: " GET M IDCODE PICTURE "!999" 


0 8,15 SAY "OR PRESS RETURN TO QUIT" 


IF M IDCODEe "^" 
EXIT 
ENDIF 


USE PERSON 
LOCATE FOR IDCODE=M_IDCODE 
IF FOUND() G&PERSON DOES EXIST IN MASTE 
RIGRT =" " 
SET FORMAT TO CMEVAL 
READ 
IF RIGHT e "Y" &&the right person 
USE CMEREQ 


P FILE 


SET FILTER TO IDCODE-M IDCODE .AND. FY-M FY 


CLEAR 

@ 6,0 

DISPLAY FIELDS IDCODE, TYPE, STAPT, 
IDCODE=M_IDCODE 

@ 20, O CLEAR 


END WHILE 


@ 22,0 SAY "ENTER TRE RECORD NUMBER OF THE 


CME REQUEST YOU DESIRE TO DELETE. (1- 
"*STR(RECCOUNT (),4) *") "; 
GET RECORD PICTURE "9999" 
READ 


IF RECORD > 0 .AND. RECORD < RECCOUNT() 


GOTO RECORD 
SET FORMAT TO DELCMEREQ 
READ 
IF UPPER(MAYBE)e "Y" 
DELETE 
ENDIF 
CLOSE FORMAT 
ELSE 
€ 20,0 CLEAR 
@ 23,5 SAY "NO SUCH RECORD: 
"4 STR (PECORD, 4) 

? CBR(7) 
WAIT 

ENDIF 


6,0 TO 8,79 DOUBLE 
7,15 SAY "THERE IS NOT A PERSON WI 
IDCODE, PRESS RETURN TO TRY AGAIN..." 
WAIT " " 
LOSE 
ENDIF 
ENDDO 
SET FILTEP TO 
SET TALK ON 
CLEAR 
8 2,0 SAY * ' 


TH TRAT 


? “PACKING DATABASE TO REMOVE RECORDS MAPKED FOR 


DELETION’ 
PACK 


SET TALK OFF 

SET CONFIPM OFF 

STORE ' ' TO wait subst 

€ 23,0 SAY 'Fress any key to continue.. 
wait subst 

READ 


ETE 


SET CONFIRM ON 


CASE selectnum = 4 
E DO FE LEN INECOTMATION 

SELECT A 

USE CMEREO 

INDEX ON IDCODE TO TEMF 

SELECT B 

USE PERSON 

INDEX ON IDCODE TO TEMP1 

JOIN WITR A TO TEMPJOIN FOR IDCODE=A->IDCODE FIELDS 
A->IDCODE, B->RANK, B->FNAME, ; 

B->LNAME, A->TYPE,A->START, A->END, A->LOCATION, A- 

>PURPOSE, ; 
A->TVLCOST,A->PERDIEM,A->REGFEE,A->REIMB, ÁA- 
>TOTALCOST, ; 

A->C_CODE,A->FY 

USE TEMPJOIN 

SET FILTER TO FY=M_FY 

BROWSE NOAPPEND NOMENU 

ERASE TEMP .NDX 

ERASE TEMP1.NDX 

ERASE TEMPJOIN.DBF 

SET CONFIRM OFF 


STORE ' ' TO wait subst 
@ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 
READ 
SET CONFIRM ON 
ENDCASE 
ENDDO T 
RETURN 


* EOF: PMENU4_2.PRG 
^Z 





* Program..: 


PMENUA 3.PRG 


* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date.....: 02/02/89 
* Notice...: Copyright (ei 1989, ELBERT T. SHAW £ JOAN 


ZIMMERMAN, All Rights Reserved 
* Notes....: UPDATE CME REQUEST WITH ACTUAL COSTS 


SET TALK OFF 
SET BELL OFF 


SET ESCAPE OFF 
SET CONFIRM ON 
M FY = 0 


* Clear Screen for FY input an allow for the user to select 
the Fiscal Year 
* Typically, the user will only be operating in one FY 


CLEAR 
@6,0 to 8,79 DOUBLE 
87,15 SAY "Enter the Fiscal Year for the CME Allecations:" ; 


GET M FY PICTURE "99" 
READ 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
$ draw menu border and print heading 
CLEAR 


M_IDCODE = SPACE (5) 
RECORD = 0 
@ 6,0 TO 8,79 DOUBLE 
8€ 7,15 SAY "ENTER THE ID CODE OF THE PERSON YOU WANT TO 
UPDATE WITH ACTUAL COST OF TRAVEL"; 
GET M IDCODE PICTURE "!999" 
READ 
USE CMEREQ 
SET FILTER TO IDCODE-M IDCODE .AND. 
CLEAR 
e 6,0 
DISPLAY FIELDS IDCODE, TYPE, STAPT, END WHILE 
IDCODE=M_IDCODE 
@ 20, O CLEAR 
@ 22,0 SAY “ENTER THE RECORD NUMBER OF THE CME PEQUEST 
YOU DESIRE TO CRANGE. (1-"+STR(RECCOUNT (),4)+")"; 
GET RECORD PICTURE "9999" 
READ 
IF RECORD > O .AND. RECORD < RECCOUNT () 
GOTO RECORD 
SET FORMAT TO UPCMEPEO 
REPLACE C_CODE MITH A 
READ 


FY-M FY 
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REPLACE TOTALCOST NITH TPAVELCOST+PERDIEM+REGFEE+REIMB 
CLOSE FORMAT 
ELSE 
A 20,0 CLEAR 
@ 22,5 SKY "MO SUCH RECORD: 
? CHR(7) 
WAIT 
ENDIF 
ENDDO T 
RETURN 
* EOF: PMENU4 3.PRG 
^2 


"+STP (RECOFD, 4) 


* Program..: 
PMENU4 4.PRG 


* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN 
* Date.....: 02/02/89 
* Notice...: Copyright (c) 1989, ELBERT T. SHAW & JOAN 


ZIMMERMAN, All Rights Reserved 
* Notes....: PRINT CME REPORTS 


SET TALK OFF 

SET BELL OFF 

SET ESCAPE OFF 

SET CONFIRM ON 

M FY = 0 

* Clear Screen for FY input an allow for the user to select 
the Fiscal Year 

* Typically, the user will only be operating in one FY 


CLEAR 
46,0 to 8,79 DOUBLE 
87,15 SAY "Enter the Fiscal Year for the CME Allocations:" ; 


GET M_FY PICTURE "99" 
READ 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
* draw menu border and print heading 

CLEAR 

€ 2, O TO 11,79 DOUBLE 


8 3,23 SAY [PRINT C ME 

@ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

@ 7,30 SAY [1. ESTIMATED CME EXPENSES REPORT FOR FY) 

*STR(M FY,2) 

@ 8,30 SAY (2. ACTUAL CME EXPENSES REPORT FOR 
FY)*STR(M FY,2) 

@ 10,34 SAY 'O. EXIT' 

STORE O TO selectnum 

@ 11,33 SAY " select n 

@ 11,42 GET selectnum PICTURE 

READ 


REPORT S] 


"9" RANGE 0,0 


DO CASE 
CASE selectnum = O 
CLEAR ALL 
RETURN 


CASE SELECTNUM = 1 


* JOIN CMEREQ WITH PERSON TO JOINFILE FOR IDCODE 
*USE CMEALLOC AND GET ALLOCATION FOR SELECTED FY 
*STORE ALLOCATION TO FY_ALLOCATION 

*USE JOINFILE INDEXED ON START DATE 

*SET FILTER TO FY=M_FY 

*SUM TOTAL FOR C_CODE="A" TO A_TOTAL 

*SUM TOTAL FOR C CODE-"E" TO E TOTAL 

*REPORT MILL DISPLAY FY ALLOCATION LESS A TOTAL AND 
£ TOTAL ESTIMATED COSTS REMAINING, E_TOTAL 

* 


*ESTIMATED CME REPOPT PPINTED HERE 
CASE SELECTNUM = 2 


* JOIN CMEREQ WITH PERSON TO JOINFILE FOR IDCODE 
*USE CMEALLOC AND GET ALLOCATION FOR SELECTED FY 
*STORE ALLOCATION TO FY_ ALLOCATION 

*USE JOINFILE INDEXED ON START DATE 

*SET FILTER TO FY=M_FY 

*SUM TOTAL FOR C_CODE="A" TO A_TOTAL 

*SUM TOTAL FOR C CODE-"E" TO E TOTAL 

*SET FILTER TO 

*SET FILTEP TO C_CODE="A" .AND. FY-M FY 

*REPORT WILL DISPLAY FY ALLOCATION LESS A TOTAL 
*BUT WILL NOT DISPLAY ESTIMATED ENTRIES 

*TOTAL ESTIMATED COSTS,E TOTAL, REMAINING WILL BE A 


COMMENT AT BOTTOM 
x OF REFORT 
* 


ACTUAL CMF PFPORT PRTNTED REPE 


ENDCASE 


ENDDO T 

RETURN 

* EOF: PMENU4 4.PRG 
22 


REPLACE FY WITH M FY 
READ 
REFLACE DUPATION 
US fe A E 
SET FILTER TO 
LOOP 

ELSE 
LOOP 

ENDIF 

ELSE 
@ 6,0 TO 8,79 DOUBLE 
& 7,15 SAY "THERE IS NOT A PERSON WITH THAT 


WITH END-STAPT 


d SE PRESS RETURN TO TRYJAGAIN. .." 

WAIT " "7 
LOOP 

* Program..: ENDIF 

PMENU5.PRG ENDDO 

* Author...: ELBERT T. SHAW & JOAN ZIMMERMAN APPEND 

* Date.....: 02/02/89 

* Notice...: Copyright (c) 1989, ELBERT T. SHAW £ JOAN SET CONFIPM OFF 

ZIMMERMAN, All Rights Reserved STORE * ' TO wait subst 

* Notes....: UPDATE LEAVE/ABSENSE REQUESTS @ 23,0 SAY ‘Press any key to continue...’ GET 

wait subst 


SET TALK OFF 
SET BELL OFF 
SET ESCAPE OFF 
SET CONFIRM ON 
USE ABSENCE 
HEI = 0 R 
* Clear Screen for FY input an allow for the user to select 
the Fiscal Year 

* Typically, the user will only be operating in one FY 
CLEAR 

@6,0 to 8,79 DOUBLE 

87,15 SAY "Enter the Fiscal Year for the CME Allocations:" ; 


WANT TO 


GET M FY PICTURE "99" 


READ 
DO MHILE ,T. 
* ---Display menu options, centered on the screen. 
* draw menu border and prínt heading 
CLEAR 
@ 2, 0 TO 14,79 DOUBLE S 


@ 3,12 SAY [UPDATE 
S T INGS) 

@ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

€ 7,30 SAY [1. ENTER A NEW LEAVE REQUEST FOR FY 
J+STR(M_FY, 2) 

@ 8,30 SAY [2. 

+STR(M_FY, 2) 

@ 9,30 SAY [3. REMOVE A LEAVE REQUEST FROM FY 

}+STR(M FY, 2) 


LEAVE/ABSENCE L I 


CHANGE CURPENT LEAVE INFORMATION FOP FY) 


IDCODE=M_IDCODE 


READ 
SET CONFIRM ON 


CASE selectnum = 2 


DO CHANGE INFOPMATION 
DO WHILE 
@ 6,0 TO 9,79 DOUBLE 
@ 7,15 SAY "ENTER THE ID CODE OF THE PEPSON YOU 
CRANGE: " GET M IDCODE PICTURE "!999" 
@ 8,15 SAY "OR PRESS RETURN TO QUIT" 


otc 


IF M IDCODE= "" 
EXIT 
ENDIF 


USE FEPSON 

LOCATE FOR IDCODE=M_IDCODE 

IF FOUND () &&PEPSON DOES EXIST IN MASTER FILE 
ANSWER » " " 
MESSAGE= "IS THIS TRE PERSON YOU EXPECTED? (Y/N) 

SET FORMAT TO CONFIRM 

READ 

IF ANSWER = "Y" &&the right person 

USE ABSENCE 

CLEAR 

e 6,0 

DISPLAY FIELDS IDCODE, TYPE, STAPT,END WHILE 


e 20, O CLEAR 


@ 22,0 SAY “ENTER THE RECOPD NUMBEP OF THE 


@ 10,30 SAY [4. REVIEW LEAVES FOR FY ]+STR(M FY, 2) LEAVE REQUEST YOU DESIRE TO CHANGE. (1-" + 
& 12, 30 SAY ro EXIT Ce STR(RECCOUNT (), 4) *") "; 
STORE O TO selectnum GET RECORD PICTURE "9999" 
8 14,33 SAY " select 2 READ 
@ 14,42 GET selectnum PICTURE "9" RANGE 0,4 IF RECORD > 0 .AND. RECORD < RECCOUNT () 
READ CLEAR 
GOTO RECORD 
DO CASE SET FORMAT TO ABSENCE 
CASE selectnum = 0 READ 
CLEAR ALL REPLACE DURATION WITH END-START  &&COMPUTE 
RETURN A or DAYS 
CLOSE FORMAT 
CASE selectnum = 1 EXIT 
* DO ADD INFORMATION ENDDO 
USE ABSENCE ELSE 
DO WHILE ,T. @ 20,0 CLEAR 
@ 6,0 TO 9,79 DOUBLE @ 23,5 SAY "NO SUCH RECORD: 
@ 7,15 SAY “ENTER THE ID CODE OF TRE PEPSON TO ADD "*STR (RECORD, 4) 
THE LEAVE REQUEST: " GET M IDCODE PICTURE "!999" ? CBR (7) 
@ 8,15 SAY "OR PRESS RETURN TO QUIT" WAIT 
ENDIF 
IF M IDCODE= "" SET FILTER TO 
EXIT LOOP 
ENDIF ELSE 
SET FILTEP TO 
USE PEPSON LOOP 
LOCATE FOR IDCODE-M IDCODE ENDIF 
IF FOUND() &&PEPSON DOES EXIST IN MASTER FILE ELSE 
ANSWER —- " " @ 6,0 TO 8,79 DOUBLE 
MESSAGE= "IS THIS THE PEPSON YOU EXPECTED? (Y/N) @ 7,15 SAY “THEFE IS NOT A PEPSON WITH THAT 
n IDCODE, PRESS RETURN TO TRY AGAIN..." 
SET FORMAT TO CONFIRM MATT 7 
READ LOOP 
IF ANSWER - "Y" &&the right person ENDIF 
USE ABSENCE ENDDO 
SET FILTER TO FY-M FY SET FILTEP TO 
GO TOP 
SET FORMAT TO ABSENCE SET CONFIFM CFF 
APPEND BLANK STORE ' ' TO wait subst 
REPLACE IDCODE WITH M IDCODE @ 23,0 SAY 'Press any key to continue...' GET 
E wait subst 
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READ 
SET CONFIRM ON 


CASE selectnum = 3 
* DO REMOVE INFORMATION 


DO WHILE .T. 
@ 6,0 TO 9,79 DOUBLE 
@ 7,15 SAY "ENTER THE ID CODE OF THE PERSON TO 


DELETE THEIR LEAVE REQUEST: " GET M IDCODE PICTURE 
2019.99 
8 8,15 SAY "OR PRESS RETURN TO QUIT" 
IF M IDCODE- "" 
EXIT 
ENDIF 
USE PERSON 
LOCATE FOR IDCODExzM IDCODE 
IF FOUND() 66PERSON DOES EXIST IN MASTER FILE 
ANSWER - " " 
MESSAGE= "IS THIS THE PERSON YOU EXPECTED? (Y/N) 
n 
SET FORMAT TO CONFIRM 
READ 
IF ANSMEP - "Y" &&the right person 
USE ABSENCE 
SET FILTER TO IDCODE=M_IDCODE .AND. FY=M_FY 
CLEAR 
@ 6,0 
DISPLAY FIELDS IDCODE, TYPE, START, END WRILE 
IDCODE=M_IDCODE 
e 20, O CLEAR 
8 22,0 SAY "ENTER TRE RECORD NUMBER OF TRE 
LEAVE REQUEST YOU DESIRE TO DELETE. (1-"+ 


STR (RECCOUNT (), 4) *"7) "; 
GET RECORD PICTURE "9999" 

READ 

IF RECORD > O .AND. RECORD < RECCOUNT () 
GOTO RECOPD 
SET FORMAT TO DELLEAVE 
READ 
1F UPPER(MAYBE)= "Y" 

DELETE 

ENDIF 
CLOSE FORMAT 

ELSE 
€ 20,0 CLEAR 
8 23,5 SAY "NO SUCH RECORD: 

"+STR(RECORD, 4) 
? CHR(7) 
WAIT 
ENDIF 
LOOP 
ELSE 
@ 6,0 TO 8,79 DOUBLE 
e 7 


,15 SAY "THERE IS NOT A PERSON WITH THAT 
IDCODE, PRESS RETURN TO TRY AGAIN..." 
WAIT " " 
LOOP 
ENDIF 
ENDDO 


SET FILTER TO 

SET TALK ON 

CLEAR 

e 2,0 SAY ' ’ 

? 'PACKING DATABASE TO REMOVE RECORDS MARKED FOR 
DELETION’ 

PACK 


SET TALK OFF 

SET CONFIRM OFF 

STORE * ' TO wait subst 

@ 23,0 SAY *Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 4 
* DO REVIEW INFORMATION 
SELECT A 
USE ABSENCE 
INDEX ON IDCODE TO TEMP 
SELECT B 
USE PERSON 
INDEX ON IDCODE TO TEMP1 
JOIN WITH A TO TEMPJOIN FOR IDCODE*A->IDCODE FIELDS 
A->IDCODE, B->RANK, B->FNAME, ; 
B->LNAME, A->TYPE,A->START,A->END, A->DURATION, ; 
A->COMMENT, A->F Y 
USE TEMPJOIN 
SET FILTER TO FY=M FY 
BROMSE NOAPPEND NOMENU 
ERASE TEMP.NDX 
ERASE TEMP1.NDX 
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EFASE TEMPJOIN.DBF 

SET CONFIRM OFF 

STORE * ’ TO wait subst 

A 23,0 SAY ‘Frese any key to continue...’ 
wait subst 

READ 

SET CONFIPM ON 


ArT 


ENDCASE 


ENDDO T 
RETURN 

t EOF: 

oe 


PMENUS .PRG 


* Program..: 


PMENUG.PRG 
* Author...: ELBERT T. SHAM & JOAN ZIMMERMAN 
* Date..... + 02702789 


* Notice...: Copyright (c) 1989, 
ZIMMERMAN, All Rights Reserved 

* Notes....: PRINT PERSONNEL REPORTS 

SET TALK OFF 

SET BELL OFF 

SET ESCAPE OFF 

SET CONFIRM ON 

DO WHILE .T. 

M FY-0 

* Clear Screen for FY input an allow for the user to select 
the Fiscal Year 

* Typically, the user will only be operating in one FY 
CLEAR 

86,0 to 8,79 DOUBLE 


ELBERT T. SHAW & JOAN 


87,15 SAY "Enter the Fiscal Year for the CME Allocations:" ; 
GET M FY PICTURE "99" 
READ 
* ---Display menu options, centered on the screen. 
£ draw menu border and print heading 
CLEAR 
@ 2, 0 TO 17,79 DOUBLE 


@ 3,21 SAY [PF RINT REPOPTS F OR 


]+STR(M_FY, 2) 


@ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

@ 7,24 SAY [1. Position Listing] 

@ 8,24 SAY [2. Section Update Worksheet] 

e 9,24 SAY [3. Loss Report] 

@ 10,24 SAY [4. Vacancy Listing] 

@ 11,24 SAY [S. Social Roster] 

@ 12,24 SAY [7. Monthly Absence Report] 

@ 13,24 SAY [8. Doctor Fiscal Year Absence Summary] 
a 15, 24 SAY *0. EXIT” 


STORE O TO selectnum 

@ 17,33 SAY " select T 

8 17,42 GET selectnum PICTURE "9" 
READ 


RANGE 0,8 


DO CASE 
CASE selectnum = O 
CLEAR ALL 
RETURN 


CASE selectnum = 1 
* po Position Listing 


*JOIN APC WITH TDA TO TEMPJOIN 

*JOIN TEMPJOIN WITH PERSON FOR LIKE TDA INFORMATION 

*SORT BY TDA POSITION INFORMATION 

*SUBTOTAL AUTH ON CBANGE OF TDA PARA 

*COUNT NUMBER OF RECORDS IN EACH PARAGRAPH TO GET 
ASSIGNÉD 

*POSITION LISTING REPORT PRINTED HERE 

*ERASE ALL TEMP FILES 


SET CONFIPM OFF 

STOFE * ' 10 wait subst 

@ 23,0 SAY 'Press any key to continue...” 
wait_subst 

READ 

SET CONFIPM ON 


GET 


CASE selectnum = 2 
* DO Section Update Listings 


*JOIN APC MITA TDA TO TEMFJOIN 

* JOIN TEMFJOIN WITE FEFSON FOF LIKE TDA INFOPMATION 
*SOPT BY TDA POSITION INFORMATION 

*SUBTOTAL AUTH ON CHANGE OF TDA_PARA 

*COUNT NUMBER OF RECORDS IN EACH PARAGRAPH TO GET 


ASSIGNED 
*SORT BY SECTION CODE TO GET SECTION BREAKOUTS, 
SECONDARY SORT BY TDA INFORMATION 
*INCLUDE BLANK CHANG3GE FIELDS, SF.F FXAMPLE REFORT 
*SECTION UFDATE WORKSHEET REEOFT FRINIED HERE 
*ERASE ALL TEMP FILES 
SET CONFIRM OFF 
STORE * * TO wait_subst 
@ 23,0 SAY “Press any key to continue...” GET 
wait_subst 
READ 
SET CONFIFM ON 


CASE selectnum = 3 
* DO Loss Report 


StartDate 

STORE SPACE(8) TO StartDate, EndDate 

CLEAR 

@6,0 to 9,79 DOUBLE 

87,15 SAY "Enter the start date:" ; 

GET StartDate PICTURE "99/99/99" 
Q 8,15 SAY "Enter the ending date:"; 
GET EndDate PICTURE "99/99/99" 

READ 

STORE CTOD (Startdate) TO StartDate 

STORE CTOD (EndDate) TO EndDate 

* JOIN TDA WITH PERSON TO TEMPJOIN FOR SAME TDA 
POSITION 

*FIELDS 
RANK, LNAME, FNAME, JOBTITLE,ALOSS, TDA_FARA, LINE,AND POSN 

*USE TEMPJOIN &&LIST OF ALL PERSONS WITH THEIR 
JOBTITLE 

* INDEX ON ALOSS 

*SEEK STARTDATE 

2£---DECIDE WHETHER TO PROCEED WITH SEEK APFROACH 

2---OR RENERT TO SLOWER, SAFER FOR APPROACH 

*IF FOUND () 

X LIST WHILE ALOSS «« STARTDATE 


E IF POSN-99 

o USE TDA 

E LOCATE TDA FARA .AND. TDA LINE 

£ PRINT JOBTITLE 

* ENDIF 

*ELSE 

x LIST FOR ALOSS »- STARTDATE .AND. ALOSS «- 
ENDDATE 

ES IF POSN=99 

$ USE TDA 

t LOCATE TDA PARA .AND. TDA LINE 

2 PRINT JOBTITLE 

2 ENDIF 

*ENDIF 

*LOSS REPORT FRINTED HEFE 

*ERASE ALL TEMP FILES 

SET CONFIRM OFF 

STORE ' ' TO wait subst 

8 23,0 SAY 'Press any key to continue...' GET 
wait subst 

READ 


SET CONFIRM ON 


CASE selectnum - 4 
* DO Vacancy Listing 


*BLANK = " " 


*JOIN APC WITH TDA TO TEMFJOIN 
*JOIN PERSON WITH TEMPJOIN FOR LIKE TDA 
INFORMATION, IF NO PERSON 
$ MATCHES A TDAPOSITION, LEAVE IDCODE AND LNAME 
BLANK 
*SORT BY TDA POSITION INFORMATION 
*COUNT FOR LNAME = BLANK .AND. IDCODE = BLANK TO 
TOTAL_VACANT 
*SET FILTER TO IDCODE=BLANK .AND. LNAME=BLANK 
x THIS SHOULD ONLY DISPLAY THE VACANT TDA 
POSITIONS 
*VACANCY REPORT PRINTED HERE 
*ERASE ALL TEMP FILES 
SET CONFIRM OFF 
STORE * ' TO wait subst 
@ 23,0 SAY 'Press any key to continue...’ GET 
wait subst 
READ 
SET CONFIRM ON 


CASE selectnum = 5 
' * DO Social Roster 


*JOIN PRIVATE WITH PERSON TO SOCIAL FOR IDCODE 
*SOCIAL ROSTER PRINTED HERE 

*ERASE ALL TEMP FILES 

SET CONFIRM OFF 

STORE ' ' TO wait subst 

Q 23,0 SAY "Press any key to continue...” GET 


walt_subst 
READ 
SET CONFIRM ON 


CASE selectnum = 6 
= DO MONTHLY ABSENCE REPORT 


MONTH = 0 

8 8,15 SAY "ENTER MONTH (i.e. 1-12) FOR THE 
REPORT:"; 

GET MONTH PICTURE "99 " RANGE 1,12 

READ 

*USE ABSENCE 

*COPY TO TEMFFILE FIELDS 
IDCODE, START, END, DURATION, FY, TYPE 

*USE CMEREQ 

*COPY TO APPENDFILE FIELDS 

IDCODE, START, END, DURATION, FY, TYPE 

*USE TEMFFILE 

*APPEND FROM APPENDFILE && JOIN CME AND LEAVE 
FILES 

*SORT BY "START" DATE, "END" DATE 

*JOIN PERSON WITH TEMFFILE TO WHOFILE && JOINS 
NAMES WITH IDCODE 

*USE WHOFILE 

*SET FILTER TO FYsM FY 

*DISFLAY WHILE [MONTH OF END DATE] * MONTH .OR. 
[MONTH OF START DATE] - MONTH 

*MONTHLY ABSENCE REPORT PRINTED HERE 

*ERASE ALL TEMP FILES 

SET CONFIFM OFF 

STORE ' ' TO wait subst 

80 23,0 SAY 'Press any key to continue...” GET 
wait_subst 

READ 

SET CONFIRM ON 


CASE selectnum = 7 
* DO DOCTOR ABSENCE REPORT 
HEI = 0 
CLEAR 
86,0 to 8,79 DOUBLE 
87,15 SAY "Enter the Fiscal Year for the ABSENCE 
REPORT: 2; 
GET M_FY PICTURE WEN 
READ 
*USE ABSENCE 
*COPY TO TEMPFILE FIELDS 
IDCODE, START, END, DURATION, FY, TYPE *USE CMEREQ 
*COPY TO APPENDFILE FIELDS 
IDCODE, START, END, DURATION, FY, TYFE 
*USE TEMPFILE 
*APPEND FROM APPENDFILE && JOIN CME AND LEAVE 
FILES 
*SORT BY "START" DATE, "END" DATE 
*JOIN FERSON WITH TEMFFILE TO WHOFILE tt JOINS 
NAMES WITH IDCODE 
*USE MHOFILE 
*SET FILTER TO FY«M FY 
*INDEX ON IDCODE 
*AVERAGE DURATION TO AVGDURATION 
*TOTAL ON IDCODE TO TOTALSUM FIELDS DURATION &&GET 
TOTAL OF ALL ABSENCES 
*ABSENCE SUMMARY REPORT PRINTED HERE, PROCEDURE 
LISTED BELOW 
*DO WHILE .NOT. EOF() && SEE ABSENCE SUMMARY REPORT 
IF IDCODE RAS CHANGED FROM PREVIOUS IDCODE 
USE TOTALSUM 
LOCATE CURRENTIDCODE 
PRINT "TOTAL DAYS ABSENT"+STR(DUPATION, 3) 
ENDIF 
DISPLAY CURRENT RECORD 
D SKIP TO NEXT RECORD 
* ENDDO 
*ERASE ALL TEMP FILES 
SET CONFIRM OFF 
STORE * * TO wadt_subst 
@ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 
READ 
SET CONFIRM ON 


» » » + » » 


ENDCASE 

ENDDO T 

RETURN 

* EOF: PMENO6.PRG 
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APPENDIX F. 


TABLE OF PROGRAMS 
SMENU. PRG 
SMENU2 . PRG 
SMENU2_1. PRG 
SMENU2_2.PRG 
SMENU2 3.PRG 


DISCLAIMER 


The purpose of this programming code is to 
facilitate the understanding of the 
requirements presented in Chapter 5 of this 
thesis. The nature of this project precludes 
it actual implementation in DBASE III*. To 
fully implement the requirements the system 
designer will need a full range of capabilities 
that does not currently exist in DBASE III*. 

DBASE III+ served as the modeling tool by 
which the screens were generated and where 
necessary, specific code was written to 
illustrate a point. The actual working code 
merely acts as a shell in which to run the 
menus. A close analysis of the program code can 
facilitate implementation in a more suitable 
language, i.e., PARADOX, which can support the 
graphics and high level relationships involved 
in the various databases. Where the actual 
requirements process may appear to be unclear, 
comments were added within the code to explain 
these areas to the designer. 


* Program..: 


SMENU . PRG 
* Author...: JOAN ZIMMERMAN & ELBERT SHAW 
* DAtQI Ot 02/19/89 
* Notice...: Copyright (c) 1989, All Rights Reserved 
* Notes....: Survey Main Menu Program 


SET TALK OFF 
SET BELL OFF 
SET STATUS OFF 
SET ESCAPE OFF 
SET CONFIRM ON 
USE SURVEY 

DO WHILE .T. 


* ---Display menu options, centered on the screen. 
* draw menu border and print heading 

CLEAR 

@ 2, 0 TO 12,79 DOUBLE 


@ 3,10 SAY [DEPARTMENT OF FAMILY PRACTICE PATIENT OPINION 
SYSTEM] 
4,1 TO 4,78 DOUBLE 
---display detail lines 
7,28 SAY (l. ENTER NEN SURVEY DATA) 
8,28 SAY (2. PRINT OFINION FESTLTS) 
Maly RE Oe Sols NIT 
STORE 0 TO selectnum 
g 12,33 SAY " select D 
€ 12,42 GET selectnum PICTURE "9" RANGE 0,2 
READ 


DODIOD 


DO CASE 
CASE selectnum = O 
SET BELL ON 
SET TALK ON 
CLEAR ALL 
RETURN 


CASE selectnum = 1 
* DO ENTER NEW SURVEY DATA 


SATISFACTION PROGRAMS 


2012 


SET FORMAT TO SURVEY 

APPEND 

CLOSE FORMAT 

SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 2 
* DO PRINT OPINION RESULTS 


DO SMENU2 


SET CONFIPM OFF 

STORE ' ' TO wait subst 

8 23,0 SAY 'Fress any key to continue...” 
wait subst 

READ 

SET CONFIRM ON 


GET 


ENDCASE 


ENDDO T 
RETURN 

* EOF: 

aes 


SMENU. PRG 





* Program..: 


BMENU2.PRG 
* Author...: JOAN ZIMMERMAN & ELBERT SHAW 
* Date.....: 02/19/89 
* Notice...: Copyright (c) 1989, All Rights Reserved 
* Notes....: Print Opinion Results 


SET TALK OFF 
SET BELL OFF 
SET STATUS OFF 
SET ESCAPE OFF 
SET CONFIRM ON 
USE SURVEY 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
x draw menu border and print heading 
CLEAR 
@ 2, O TO 15,79 DOUBLE 
g 3,21 SAY (P RINT OT I N TI OIN RESULTS) 
@ 4,1 TO 4,78 DOUBLE 
* ---display detail lines 
8 7,29 SAY [l. ACCESS TO CARE REPORTS] 
@ 8,29 SAY [2. WAITING TIME REPORTS) 
@ 9,29 SAY (3. SATISFACTION REPORTS) 
@ 10,29 SAY (4. DOCTOR REPORTS) 
@ 11,29 SAY (5. PATIENT COMMENTS) 
8 13, 29 SAY 'O. EXIT’ 
STORE O TO selectnum 
8 15,33 SAY " select n 
@ 15,42 GET selectn'um FICTURE "9" RANGE 0,5 
FEAD 
DO CASE 

CASE selectnum = 0 

RETURN 


CASE selectnum = 1 
* DO ACCESS TO CARE REPORTS 


DO SMENU2 1 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

@ 23,0 SAY ‘Press any key to continue...’ 
wait subst 

READ 


GET 


SET CONFIRM ON 


CASE selectnum = 2 
$ Mi WNAÍTTIM TT? REPORTS 


DO SMENU2_2 


SET CONFIRM OFF 

STORE * ' TO wait subst 

@ 23,0 SAY 'Press any key to continue...” 
wait subst 

READ 

SET CONFIRM ON 


GET 


CASE selectnun = 3 
* DO SATISFACTION REPORTS 


DO SMENU2_3 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

& 23,0 SAY 'Press any key to continue...” 
wait subst 

READ 

SET CONFIRM ON 


GET 


CASE selectnum = 4 
* DO DOCTOR REPORTS 


CLEAR 

M_YR=0 

M_MO=0 

6,0 TO 9,79 DOUBLE 

@7,15 SAY "Enter the Year for report:"; 

GET M YR PICTURE "99" 

READ 

88,15 SAY "Enter the Month for report:"; 
GET M MO PICTURE "99" RANGE 1,12 

READ 


***** Print Doctor Satisfaction Indicator Report 
here RRARRK 


SET CONFIRM OFF 

STORE ’ ’ TO wait subst 

@ 23,0 SAY ‘Press any key to continue...’ 
wait subst 

READ 

SET CONFIRM ON 


GET 


CASE selectnum - 5 
* DO PATIENT COMMENTS 
CLEAR 
M MỌ = 0 
M YR = 0 
@6,0 TO 9,79 DOUBLE 
@7,15 SAY "Enter the Year:"; 
GET M YR PICTURE "99" 
READ 
88,15 SAY "Enter the Month for the desired 
comments:"; 
GET M_MO PICTURE "99" RANGE 1,12 
READ 
CLEAR 
REPORT FORM PATCOMM FOR YEAR=M_YR .AND. MONTH=M_MO 


«AND. PATCOMMENTS = "Y" 
e22,0 
WAIT 

ENDCASE 

ENDDO T 

RETURN 

* EOF: SMENU2.PRG 

22 





* Program..: 


SMENU2_1.PRG 


* Author...: JOAN ZIMMERMAN & ELBERT SHAW 

* Datə.....! 02/19/89 

* Notice...: Copyright (c) 1989 All Rights Reserved 
* Notes....: Access to Care Reports 


SET TALK OFF 
SET BELL OFF 
SET STATUS OFF 
SET ESCAPE OFF 
SET CONFIRM ON 


DO WHILE .T. 
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* ---Display menu options, centered on the screen. 

‘ drew menu border and print heading 

CLEAR 

@ 2, 0 TO 12,79 DOURLE 

8 3,19 SAY (A = Fos n TO CARE PFPE FPFART I 


@ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

@ 7,32 SAY (1. DEPARTMENT REPORT) 
@ 8,32 SAY [2. CLINIC REPORT] 

@ 10, 32 SAY '0. EXIT’ 

STORE 0 TO selectnun 


& 12,33 SAY " select e 
& 12,42 GET selectnum PICTURE "9" RANGE 0, 2 
READ 
DO CASE 
CASE selectnum = 0 
RETURN 


CASE selectnum = 1 
* DO DEPARTMENT REPORTS 


CLEAR 

M YR=0 

M_MO=0 

@6,0 TO 9,79 DOUBLE 

87,15 SAY "Enter the Year for report:"; 

GET M YR PICTURE oS 

READ 

8858,15 SAY "Enter the Month for report:"; 
GET M MO PICTURE "99" RANGE 1,12 

READ 


****^* Print Dept. Acceas to Cere Report here ***** 


SET CONFIPM OFF 

STORE ' ' TO wait subst 

8 23,0 SAY 'Press any key to continue...' 
wait subst 

READ 

SET CONFIRM ON 


GET 


CASE selectnum = 2 
* DO CLINIC FEFOPTS 


CLEAR 

M_YR=0 

M_MO=0 

Se, o TO 9,79 DOUBLE 

87,15 SAY "Enter the Year for report:"; 
GET M YR PICTUPE "99" 

READ 

88,15 SAY "Enter the Month for report:"; 

GET M MO PICTURE "99" RANGE 1,12 

READ 

CLEAR 

M CLINIC umo z 

@6,0 TO 8,79 DOUBLE 

@7,15 SAY "Enter the Clinic section code for 

report: "; 

GET M CLINIC PICTURE "8!AAA" 

READ 


***** Print Clinic Access to care report here ***** 


SET CONFIRM OFF 

STORE * * TO wait subst 

8 22,0 SAY 'Press any key to continue...” 
wait subst 

READ 

SET CONFIRM ON 


GET 


ENDCASE 


ENDDO T 
PETURN 
* EOF: SMENU2 1.PRG 


^m 
a 


* Program..: 
BMENU2 2.PRG 


* Author...: JOAN ZIMMERMAN & ELBERT SHAW 

* Date.....: 02/19/89 

* Notice...: Copyright (c) 1989, All Rights Reserved 
* Notes....: Waiting Time Reports 


SET TALK OFF 


SET BELL OFF 

SET STATUS Off 
SET ESCAPE OFF 
SPT CONFIFM ON 


DO 


WHILE .T. 

* ---Display menu options, centered on the screen. 
* draw menu border and print heading 

CLEAR 

Q 2, O TO 12,79 DOUBLE 

8 3,21 SAY [HA 1 T ING 2v 26 jy] E REPOR T S] 
@ 4,1 TO 4,78 DOUBLE 

* -—--display detail lines 

@ 7,32 SAY (1. DEPARTMENT REPORT] 

@ 8,32 SAY [2. CLINIC REPORT} 

@ 10, 32 SAY "Oo, EXIT’ 


STORE O TO selectnum 

@ 12,33 SAY " select y 

€ 12,42 GET selectnum PICTURE "9" RANGE 0,2 
READ 


DO CASE 
CASE selectnum = 0 
RETURN 


CASE selectnum = 1 
* DO DEPARTMENT REPORTS 


CLEAR 

M_YR=0 

M_MO=0 

86,0 TO 9,79 DOUBLE 

87,15 SAY "Enter the Year for report:"; 

GET M YR PICTURE "99" 

READ 

88,15 SAY "Enter the Month for report:"; 
GET M MO PICTURE "99" RANGE 1,12 

READ 


***** Print Dept. Waiting Time Report here ***** 
SET CONFIRM OFF 


STORE ' ' TO wait subst 
@ 23,0 SAY ’Press any key to continue...’ GET 


wait subst 


READ 
SET CONFIRM ON 


CASE selectnum = 2 
* DO CLINIC REPORTS 


CLEAR 

M YR-0 

M MO-0 

86,0 TO 9,79 DOUBLE 

47,15 SAY "Enter the Year for report:"; 

GET M YR PICTURE "99" 

READ 

48,15 SAY "Enter the Month for report:"; 
GET M_MO PICTURE "99" RANGE 1,12 

READ 


CLEAR 

M CLINIC =" " 

@6,0 TO 8,79 DOUBLE 

@7,15 SAY "Enter the Clinic section code for 


report: "; 


GET M CLINIC PICTURE "@!AAA” 
READ 


*?**** Print Clinic Waiting Time Report here ***** 


SET CONFIRM OFF 
STORE ' ' TO wait subst 


€ 23,0 SAY "Press any key to continue...' GET 
wait subst 
READ 
SET CONFIRM ON 
ENDCASE 
ENDDO T 
RETURN 
* EOF: SMENU2_2.PRG 
^2^2 





* Program..: 


SMENU2 3.PRGC 
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* Author...: JOAN ZIMMERMAN & ELBERT SHAW 
*oOpate; O IA 

* Notice...: Copyright (c) 1989, All Rights Reserved 
% Notes....: Salisfurtion Pep-rts 


SET TALK OFF 
SET BELL OFF 
SET STATUS Off 
SET ESCAPE OFF 
SET CONFIRM ON 


DO WHILE .T. 


* ---Display menu options, centered on the screen. 
x draw menu border and print heading 
CLEAR 
@ 2, O TO 12,79 DOUBLE 
@ 3,21 SAY [S A T 1 SF AC T on REPORTS) 
Q 4,1 TO 4,78 DOUBLE 
* ---display detail lines 
€ 7,32 SAY [1. DEPARTMENT REPORT] 
8 8,32 SAY (2. CLINIC REPORT] 
8 10, 32 SAY 'O. EXIT’ 
STORE O TO selectnum 
8 12,33 SAY " select " 
@ 12,42 GET selectnum FICTURE "9" RANGE 0,2 
READ 
DO CASE 

CASE selectnum = O 

RETURN 


CASE selectnum = 1 
* DO DEPARTMENT REPORTS 


CLEAR 

M_YR=0 

M_MO=0 

86,0 TO 9,79 DOUBLE 

87,15 SAY "Enter the Year for report:"; 

GET M YR PICTURE "99" 

READ 

88,15 SAY "Enter the Month for report:"; 
GET M MO PICTURE "99" RANGE 1,12 

READ 


***** Print Dept. aatiafaction Report here ***** 


SET CONFIRM OFF 

STORE ' * TO wait subst 

8 23,0 SAY 'Press any key to continue...' GET 
wait subst 

READ 

SET CONFIRM ON 


CASE selectnum = 2 
* DO CLINIC REPORTS 


CLEAR 

M_YR=0 

M_MO=0 

86,0 TO 9,79 DOUBLE 

87,15 SAY "Enter the Year for report:"; 

GET M YR PICTURE "99" 

READ 

48,15 SAY "Enter the Month for report:"; 
GET M MO PICTURE "99" RANGE 1,12 

READ 

CLEAR 

M CLINIC =" " 

@6,0 TO 8,79 DOUBLE 

@7,15 SAY "Enter the Clinic section code for 

report:"; 

GET M CLINIC PICTURE "@! AAA" 

READ 


Senge Print Clinic satisfaction report here ***** 


SET CONFIRM OFF 

STORE ' ' TO wait subst 

8 23,0 SAY 'Press any key to continue...’ GET 
wait subst 

READ 

SET CONFIRM ON 
ENDCASE 


ENDDO T 

RETURN 

* EOF: SMENU2 3.PRG 
52 


APPENDIX G. PRODUCTIVITY PROGRAMS 


DO VMENU] 
TABLE OF PROGRAMS SET CONFIRM OFF 
VMENU.PRG STORE ' ' TO wait subst 
VMENU1 . FRG @ 23,0 SAY ‘Press any key to continue...’ GET 
VMENU1 1.PRG wait subst 
VMENU2.PRG READ 
VMENU3.PRG SET CONFIRM ON 


CASE selectnum - 2 
* DO DEPT € CLINIC FRODUCTIVITY 


DISCLAIMER 
DO VMENU2 
The purpose of this programming code is to pe co cate tm 
e , E. wa subs 
facilitate the understanding of the d @ 23,0 SAY ‘Press any key to continue...’ GET 
reguirements presented in Chapter 5 of this wait ups? 
thesis. The nature of this project precludes READ 
it actual implementation in DBASE III+. To SET CONOS 
fully implement the requirements the system CASE sbloctnun 3 
designer will need a full range of capabilities * DO EXPENDITURE/VISIT COMPARISON 
that does not currently exist in DBASE III+. 
DBASE III+ served as the modeling tool by id 
which the screens were generated and where SET CONFIRM OFF 
necessary, specific code was written to STORE * * TO wait_subst 
illustrate a point. The actual working code @ 23,0 SAY “Press any key to continue...” GET 
: : x wait subst 
merely acts as a shell in which to run the = READ 
menus. A close analysis of the program code can SET CONFIRM ON 
facilitate implementation in a more suitable ENDCASE 
language, i.e., PARADOX, which can support the 
2 ENDDO T 
graphics and high level relationships involved RETURN 
in the various databases. Where the actual * EOF: VMENU.PRG 
requirements process may appear to be unclear, “2 


comments were added within the code to explain 
these areas to the designer. 





* Program..: 


VMENU1.PRG 
* Program..: 
VMENU . PRG * Author...: JOAN ZIMMERMAN/ELBERT SHAW 
* Dat@.....: 02/23/89 
* Author...: JOAN ZIMMERMAN/ELBERT SHAN * Notice...: Copyright (c) 1989, All Rights Reserved 
* Dato...»..»: 02/23/89 * Notes....3 
* Notice...: Copyright (c) 1989, A11 Rights Reserved SET TALK OFF 
SET TALK OFF SET BELL OFF 
SET BELL OFF SET STATUS OFF 
SET STATUS OFF SET ESCAPE OFF 
SET ESCAPE OFF SET CONFIRM ON 


SET CONFIRM ON 


DO WHILE .T. 
DO WHILE .T. 


* ---Di-play menu options, centered on the screen. 
* ---Display menu options, centered on the screen. * draw menu border and print heading 
* draw menu border and print heading CLEAR 
CLEAR & 2, O TO 12,79 DOUBLE 
€ 2, O TO 13,79 DOUBLE Q 3,24 SAY [UPDATE VISIT FILE) 
@ 3,13 SAY [DEPARTMENT OF FAMILY PRACTICE PRODUCTIVITY @ 4,1 TO 4,78 DOUBLE 
SYSTEM] * ---display detail lines 
8 4,1 TO 4,78 DOUBLE e 7,21 SAY [1. UPDATE VISIT DATA*] 
* ---display detail lines @ 6,21 SAY [2. EXTRACT VISIT DATA FROM MED302 FILE} 
e 37,25 SAY [1. UPDATE VISIT FILE] @ 10, 21 SAY ʻO. EXIT” 
@ 8,25 SAY [2. DEPT & CLINIC PRODUCTIVITY] STORE O TO selectnum 
€ 9,25 SAY [3. EXPENDITURE “VISIT COMPAPISON] @ 12,33 SAY " select " 
@ 11, 25 SAY 'O. EXIT' € 12,42 CFT selectnum FI^T"FE "9" PANGE 0,2 
STORE O TO selectnum 8 16,15 SAY "* This -ption allows you to enter visit" 
€ 13,33 SAY " select 5 @ 17,15 SAY " data from the keyboard." 
€ 13,42 GET selectnum PICTURE "9" RANGE 0,3 READ 
READ DO CASE 
CASE selectnum = O 
DO CASE RETURN 
CASE selectnum = O 
SET BELL ON CASE selectnum = 1 
SET TALK ON * DO ENTEP VISIT DATA 
CLEAR ALL 
RETURN DO VMENU1_1 
SET CONFIPM OFF 
CASE selectnum = 1 STORE ' ' TO wait subst 
* DO UPDATE VISIT FILE € 23,0 SAY 'Press any key to continue...' GET 
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wait_subst CLEAR 


READ e 2,0 SAY” 7” 
SET CONFIFM ON ? *PACKING DATABASE TO REMOVE RECORDS MARKED FOR 
DELETION’ 
CASE selectnum = 2 FACK 


* DO EXTRACT VISIT DATA FROM MED302 FILE 
SET TALK OFF 
SET CONFIRM OFF 





***** Program to extract visit data from med302 to STORE ' ' TO wait subst 
file ***=* @ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst 
SET CONFIRM OFF READ 
STORE * * TO wait subst SET CONFIRM ON 
€ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst CASE selectnum = 4 
= READ * DO REVIEW INFORMATION 
SET CONFIRM ON 
ENDCASE BROWSE NOMENU NOAPPEND 
SET CONFIRM OFF 
ENDDO T STORE ' ' TO wait subst 
RETURN & 23,0 SAY 'Press any key to continue...’ GET 
* EOF: VMENU1. PRG wait subst 
SZ READ 
SET CONFIRM ON 
ENDCASE 
ENDDO T 
* Program..:! RETURN 
VMENUl 1.PRC * EOF: VMENUl 1.PRG 
Em “pa 
* Author...: JOAN ZIMMERMAN/ELBERT SHAW 
* Date.....: 02/23/89 SENTI A E 
* Notice...: Copyright (c) 1989 All Rights Reserved 
SET TALK OFF 
SET BELL OFF * Program..: 
SET STATUS OFF VMENU2.PRG 
SET ESCAPE OFF 
SET CONFIRM ON * Author...: JOAN ZIMMERMAN/ELBERT SHAN 
USE VISIT * Dato.....: 02/23/99 
* Notice...: Copyright (c) 1989 All Rights Reserved 
DO WHILE .T. SET TALK OFF 
SET BELL OFF 
* ---Display menu options, centered on the screen. SET STATUS OFF 
* draw menu border and print heading SET ESCAPE OFF 
CLEAR SET CONFIRM ON 
@ 2, 9 TO 14,79 DOUBLE 
@ 3,24 SAY [UPDATE MISIT DA T A) DO WHILE .T. 
@ 4,1 TO 4,78 DOUBLE 
* ---display detail lines * ---Display menu options, centered on the screen. 
@ 7,30 SAY [1. ADD VISIT DATA] G draw menu border and print heading 
€ 8,30 SAY [2. CHANGE VISIT DATA] CLEAR 
@ 9,30 SAY [3. REMOVE VISIT DATA] @ 2, 0 TO 12,79 DOUBLE 
@ 10,30 SAY [4. REVIEW VISIT DATA] @ 3,15 SAY [DEPT & CLINIG PRODUCTIV 
8 12, 300SAY '*O. EXIT IT YJ 
STORE O TO selectnum @ 4,1 TO 4,78 DOUBLE 
@ 14,33 SAY " select " * ---display detail lines 
& 14,42 GET selectnum PICTURE "9" RANGE 0,4 @ 7,26 SAY [1. TOTAL MONTH VISITS] 
READ @ 8,26 SAY [2. CLINIC & DEPT VISIT TRENDS] 
e 10, 26 SAY 'O. EXIT’ 
DO CASE STORE O TO selectnum 
CASE selectnum s O Q 12,33 SAY " seloct z 
RETURN € 12,42 GET selectnum PICTURE "9" RANGE 0,2 
READ 
CASE selectnum = 1 
* DO ADD INFORMATION DO CASE 
CASE selectnum = O 
SET FORMAT TO VISIT RETURN 
APPEND 
CASE selectnum = 1 
SET FORMAT TO * DO TOTAL MONTH VISITS 
SET CONFIRM OFF 
STORE ' ' TO wait subst CLEAR 
€ 23,0 SAY 'Press any key to continue...' GET M MO-0 
wait subst M YR=0 
READ @6,0 TO 9,79 DOUBLE 
SET CONFIRM ON @7,15 SAY "Enter the year for report"; 
GET M YR PICTURE "99" 
CASE selectnum = 2 READ 
* pO CHANGE INFORMATION 85,15 SAY "Enter the month for report"; 
GEL TUNO FICTIFE “997 
SET FOPMAT TO VISIT PEAD uU 
EDIT 


****^ TOTAL MONTHa VISIT BAR CRAPH HERE ***** 
SET FOPMAT TO 


SET CONFIRM OFF SET CONFIRM OFF 
STORE ' ' TO wait subst STORE ' ' TO wait subst 
@ 23,0 SAY ‘Press any key to continue...’ GET @ 23,0 SAY ‘Press any key to continue...’ GET 
wait subst wait subst 
READ READ 
SET CONFIRM ON SET CONFIRM ON 
CASE selectnum = 3 CASE selectnum = 2 
* DO REMOVE INFORMATION * DO CLINIC & DEPT VISIT TRENDS 
SET TALK ON CLEAR 
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M MOz=O STORE * * TO wait subst 


@6,0 TO 8,79 DOUBLE @ 23,0 SAY ‘Press any key to continue...’ GET 
@7,15 SAY “Enter the year for report"; wait subst 
Ee FEAD 
READ RK SET CONFIFI1 OM 
ENDCASE 
***** CLINIC & DEPT VIBIT TREND CRAPH HERE ***** 
ENDDO T 
SET CONFIRM OFF RETURN 
STORE ' ' TO wait subst * EOF: VMENU1l.PRG 
@ 23,0 SAY ‘Press any key to continue...’ GET “2 
wait subst 
b READ 
SET CONFIRM ON 
ENDCASE 
ENDDO T 
RETURN 
* EOF: VMENU2.PRG 
^Z 


* Program..: 
VMENU3 . PRG 


* Author...: JOAN ZIMMERMAN/ELBERT SHAW 

* Date.....: 02/23/89 

* Notice...: Copyright (c) 1989, All Rights Reserved 
SET TALK OFF 

SET BELL OFF 

SET STATUS OFF 

SET ESCAPE OFF 

SET CONFIRM ON 


DO WHILE ,T. 


* ---Display menu options, centered on the screen. 
z draw menu border and print heading 
CLEAR 


@ 2, O TO 12,79 DOUBLE 
Meares SAY (EX PENDITURE/SVISIT COMPA 
RI SON) 


@ 4,1 TO 4,78 DOUBLE 

* ---display detail lines 

8 7,28 SAY (1. CLINIC EXPENDITUFE PER VISIT REPORT] 

@ 6,28 SAY (2. DEPT. EXPENDITURE VS VISIT TREND REPORT} 
@.10, 28 SAY ‘0. EXIT’ 


STORE O TO selectnum 


8 12,33 SAY " select z 
@ 12,42 GET selectnum PICTURE "9" RANGE 0,2 
READ 
DO CASE 
CASE selectnum = O 
RETURN 


CASE selectnum e 1 
* po CLINIC EXPEND. PER VISIT 


CLEAR 

M_MO=O 

H "Pet 

86,0 TO 9,79 DOUBLE 

87,15 SAY "Enter the year for report"; 
GET M YR PICTURE "99" 

READ 

88,15 SAY "Enter the month for report"; 

GET M MO PICTURE "99" 
READ 


***** Print Clinic months exp/visit report here 
hhkkk 


SET CONFIRM OFF 


STORE ' ' TO wait subst 

8 23,0 SAY 'Press any key to continue...” GET 
wait subst 

PEAD 


SET CONFIRM ON 


CASE selectnum = 2 
* DO EXPEND. VS VISIT TREND 
CLEAR 
M_YR=0 
86,0 TO 8,79 DOUBLE 
87,15 SAY "Enter the year for report"; 
GET M YR PICTURE "99" 
READ 


***** Print Dept EXP VS VISIT TREND REPORT HERE 


DCL 
SET CONFIRM OFF 
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